[Discuss-gnuradio] What does the EEPROM do on rfx board?
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 the clock is successfully syncronized. But I didn't burn the eeprom, so I want to know what does the burned eeprom do? I saw there are several version of eeprom fireware, rfx2400_tx, rfx2400_mimo_a, rfx2400_mimo_b, what is the difference with mimo_a and mimo_b? Thanks. hanwen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build errors
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 the log file that Bob sent me and compared it to >> what I see on my machines. The difference appears to be something in >> libtool. >> >> >> > > > ---snip > >> Although they both make the same call to libtool, libtool spits out a >> different command line on the two systems. On Bob's (and I assume >> Illix's) machine, the output of libtool contains --rpath (pointing to >> the install, not build directory!), whereas my machine lists the >> actual paths needed to find the pieces. >> > > I did a test before I read this note. I ran make install in the pmt > directory after the mblock make fails. After this bandaid step, if I > run make in the trunk directory, the make succeeds. I concur with your > analysis. Don't you hate these kinds of issues? > >> Bob's machine is using >> ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 >> 2005/12/18 22:14:06) >> >> I'm using (SuSE 10.1) >> >> ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) >> >> It looks like the Debian folks may have applied some kind of a patch to >> libtool 1.5.22 that could be causing the problem. >> >> Can any debian/ubuntu users figure out the difference? That is, >> what's the debian/ubuntu patch, and when and why was it applied? I found this on the debian buglist for libtool: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320698 Message received at [EMAIL PROTECTED] (full text, mbox): From: Philip Martin <[EMAIL PROTECTED]> To: Loïc Minier <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Bug#320698: Debian-specific binary deps patch Date: Thu, 06 Oct 2005 01:24:03 +0100 > It seems that Debian's libtool has a patch which will reduce > dependencies in binaries it produces. One of the knock-on effects of this patch is bug 291641 where ld resolves symbols using installed libraries instead of libraries in the build directory. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641 Subversion 1.2 has a Build-Conflicts with Subversion 1.1 to avoid this problem. Greetings, Martin >> >> Thanks, >> Eric >> >> > > > Bob > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build errors
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 sent me and compared it to what I see on my machines. The difference appears to be something in libtool. ---snip Although they both make the same call to libtool, libtool spits out a different command line on the two systems. On Bob's (and I assume Illix's) machine, the output of libtool contains --rpath (pointing to the install, not build directory!), whereas my machine lists the actual paths needed to find the pieces. I did a test before I read this note. I ran make install in the pmt directory after the mblock make fails. After this bandaid step, if I run make in the trunk directory, the make succeeds. I concur with your analysis. Don't you hate these kinds of issues? Bob's machine is using ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06) I'm using (SuSE 10.1) ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) It looks like the Debian folks may have applied some kind of a patch to libtool 1.5.22 that could be causing the problem. Can any debian/ubuntu users figure out the difference? That is, what's the debian/ubuntu patch, and when and why was it applied? Thanks, Eric Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest." - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build errors
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 on my machines. The difference appears to be something in libtool. My machine (works): /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o test_mblock test_mblock.o libmblock-qa.la libmblock.la g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock test_mblock.o ./.libs/libmblock-qa.so /home/eb/gr/trunk/mblock/src/lib/.libs/libmblock.so /usr/lib/libcppunit.so -ldl ./.libs/libmblock.so /home/eb/gr/trunk/pmt/src/lib/.libs/libpmt.so /usr/lib/libstdc++.so Bob's machine (doesn't work): /bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o test_mblock test_mblock.o libmblock-qa.la libmblock.la g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock test_mblock.o ./.libs/libmblock-qa.so ./.libs/libmblock.so -Wl,--rpath -Wl,/usr/local/lib Although they both make the same call to libtool, libtool spits out a different command line on the two systems. On Bob's (and I assume Illix's) machine, the output of libtool contains --rpath (pointing to the install, not build directory!), whereas my machine lists the actual paths needed to find the pieces. Bob's machine is using ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06) I'm using (SuSE 10.1) ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) It looks like the Debian folks may have applied some kind of a patch to libtool 1.5.22 that could be causing the problem. Can any debian/ubuntu users figure out the difference? That is, what's the debian/ubuntu patch, and when and why was it applied? Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interpretting results from usrp_rx_cfile.py
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 commands I tried: > > # ./usrp_rx_cfile.py -R B -d 256 -f 1000 sine_1k1.dat > # ./usrp_rx_cfile.py -R B -d 256 -f 1 sine_1k10.dat > # ./usrp_rx_cfile.py -R B -d 256 -f 15000 sine_10k15.dat > > The function generator was producing a 1kHz sine wave for the first two > and a 10kHz sine wave for the third. > > Each time I captured a few seconds worth of data. I then took the data > files and extracted two streams of single precision floats for each of > the first ten thousand 8-byte groups in the file and plotted them. The > results were very similar regardless of the frequency specified on the > command line (and I have no idea what that frequency is for) or the > actual frequency of the signal that was applied to the inputs. > > What I got in all cases was basically a flat line (-3 to +3) except for > in the vicinity of sample #530, which looks like an inverted sinc pulse > with a peak amplitude of about -1 (the first stream, which is made > up of the first float value in each sample pair), and what looks like an > extremely heavily damped sine wave (the second stream) with a peak > amplitude of about 20,000 and roughly centered at the same place as the > sinc pulse. > > This makes absolutely no sense to be whatsoever. Can anyone shed any > light on this? > > Thanks The Basic RX only passes signals > 100kHz. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Interpretting results from usrp_rx_cfile.py
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 commands I tried: # ./usrp_rx_cfile.py -R B -d 256 -f 1000 sine_1k1.dat # ./usrp_rx_cfile.py -R B -d 256 -f 1 sine_1k10.dat # ./usrp_rx_cfile.py -R B -d 256 -f 15000 sine_10k15.dat The function generator was producing a 1kHz sine wave for the first two and a 10kHz sine wave for the third. Each time I captured a few seconds worth of data. I then took the data files and extracted two streams of single precision floats for each of the first ten thousand 8-byte groups in the file and plotted them. The results were very similar regardless of the frequency specified on the command line (and I have no idea what that frequency is for) or the actual frequency of the signal that was applied to the inputs. What I got in all cases was basically a flat line (-3 to +3) except for in the vicinity of sample #530, which looks like an inverted sinc pulse with a peak amplitude of about -1 (the first stream, which is made up of the first float value in each sample pair), and what looks like an extremely heavily damped sine wave (the second stream) with a peak amplitude of about 20,000 and roughly centered at the same place as the sinc pulse. This makes absolutely no sense to be whatsoever. Can anyone shed any light on this? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build errors
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 machines I described, all running Ubuntu 6.1 32bit, exhibit the > problem. This is 3 independent machines. I svn fresh copies of the > source and did > > ./bootstrap;./configure --enable-doxygen;make > > and the make fails on all three machines. HP laptop, Mini-ITX P4-HT, > and old dual Athlon-MP SMP machine. > > Bob Bob, If you send me output from the set of command's I sent in the off-list message I'll take a look at it. I need more info to sort this out. Eric > > Johnathan Corgan wrote: > >On Mon, 2007-01-15 at 22:47 -0500, Robert McGwier wrote: > > > > > >>Eric and others are NOT experiencing this so I am trying to figure out > >>what is going wrong on my 3 Ubuntu 6.1 machines with the problem. > >> > > > >Just FYI, using Ubuntu 6.1 (32-bit) here with no issues. > > ___ 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] x86_64 path proposal
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 will not be found first. > >(Fedora should have a lib32/python2.4/site-packages, but it depends on > >path ordering to do that). > > > > Despite the fact that this solution works, I do not think it is > "correct". No python application distributed by Fedora is split > between lib and lib64. Packages are either installed in lib or lib64. > The only time packages appare to be split between the two folders is > when both the i386 and x86_64 version is installed. From what I know, > SuSE also install x86_64 python programs only in lib64. I therefore > think the correct solution would be to install everything either in > lib64 or in lib. > I agree that our current fix (do nothing) for X86-64 on Fedora Core is insufficient. I've reopened ticket:39 and will kludge our code to work around the brain damage in FC. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PlayStation 3
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 a little time trying to build GNU Radio for my EFIKA board > using OpenEmbedded. Currently, I have the configure script running to > the point it starts looking for cppunit. It fials there. I suspect > some hacking at the OE recipe for cppunit may be required in order for > the GNU Radio configure script to find it. > > Now I will demonstrate my lack of understanding of GNU Radio :) > > I suspect cppunit generates the checks used by the make check step of > the build instructions. Since this is a cross build, non of the > executables will actually run on the build system. I should be able to > make the test programs, but they would need to run on the target > system. While it should be possible to work out the cppunit problem I > have, in the short term, is there a way to disable the need for > cppunit? Even in the cross compilation environment, the cppunit stuff should build and link OK. Running the tests on the host machine is a different problem, but solving that isn't specific to cppunit. We'll also have the same problem with all of the "make check" tests. There's no easy way to remove the cppunit stuff. You'd have to edit a good percentage of the Makefile.am's. I think that we ought to build the unit tests. They should be runnable once everything is installed on the host system. > If anyone is seriously interested in building GNU Radio with OE, I'd > be glad to help get you started. Thanks for your offer! In general, is OE the answer, or are there other cross development environments that we should be looking at? It looks like OE was designed to solve the "build an entire system image, including kernel, boot loader, etc". That may be overkill for the PS3. On the other hand, if OE solves the "configure in the cross development environment", then maybe it is the easiest way to get going. Ultimately with the cell, I suspect that we need a "dual cross-compilation" environment since you need two tool chains installed, one for the PPE and one for the SPE. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample rate nomenclature
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 from float to complex sampling. source_c, decim == 8: 8 MS/s source_f, decim == 8: ? MS/s Thanks, Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PlayStation 3
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 Dog pre-installed PS3 list if you have not > > already done so. They have taken the $100 with no guarantee and they > > will not even hazard a guess as to a delivery date. I did not save a > > single dime since I could have download FC5 and IBM Cell SDK2.0 for free > > and done the install myself and purchased the thing from Fry's or > > elsewhere. IBM has a step by step procedure for doing the Linux > > install on their web site. Myriad videos doing disk drive upgrades, > > etc. are on YouTube.I am not pleased with Terra AT ALL. People are > > able to get one and leave the store from Fry's and do the install > > themselves. I do not want to wait until March so I am going to use an > > extra lever I have that most people do not have (think of it as the fake > > wheel chair person going to the head of the line at Disney World and you > > will understand) but this is good for one only. > > > > Bob > > Hello Bob, > > Thanks for the information. I had questions on how to install linux on > the thing. Alot easier than the XBox. > http://www-128.ibm.com/developerworks/power/library/pa-linuxps3-1/ > > The web page indicates the video options may be limited. No VGA and the > HDMI requires monitors with HCP. There appear to be some HDMI to DVI cables available. I've ordered one, but it hasn't come yet. > Likely Terra is low on the allocation list since they are not a major > game retailer. > > 73 Eric Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample rate nomenclature
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 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, would I >> advertise it as "Complex data, 4 million samples per second"? >> > > Call it 8 MS/s complex. > > >> Q3: If someone read that in using file_source(gr.sizeof_gr_complex, >> "file.in") and wanted to perform an FFT, what would he specify as the >> sample rate to the fft_sink_c(sample_rate=x)? My guess is >> sample_rate=4e6. >> > > 8e6. > > Matt > > > ___ > 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] Input Voltage Range of BasicRX board
> 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 mail archives, and the user's guide have it. The schematics are the final arbiter... Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Input Voltage Range of BasicRX board
> -Original Message- > From: Matt Ettus [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 12:20 PM > To: Bahn William L Civ USAFA/DFCS; gnuradio mailing list > Subject: Re: [Discuss-gnuradio] Input Voltage Range of BasicRX board > > 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 voltage Thanks. Does this mean that the signals need to be DC offset so as never to go below ground? > > > 2) Without exceeding the range of the ADC? > > > > The full-scale range of the ADC is 2 V pk-pk Is there an offset, or is it 0V to 2V? > > > Surely this kind of stuff is documented someplace. But where? I can't > > find anything on the Ettus website that has it. Is there someplace where this is documented? Thanks a lot. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample rate nomenclature
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, would I > advertise it as "Complex data, 4 million samples per second"? Call it 8 MS/s complex. > > Q3: If someone read that in using file_source(gr.sizeof_gr_complex, > "file.in") and wanted to perform an FFT, what would he specify as the > sample rate to the fft_sink_c(sample_rate=x)? My guess is > sample_rate=4e6. 8e6. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Input Voltage Range of BasicRX board
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 voltage > 2) Without exceeding the range of the ADC? > The full-scale range of the ADC is 2 V pk-pk > Surely this kind of stuff is documented someplace. But where? I can't > find anything on the Ettus website that has it. > > Thanks. > > > > > ___ > 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: Help - please
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sample rate nomenclature
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"? Q3: If someone read that in using file_source(gr.sizeof_gr_complex, "file.in") and wanted to perform an FFT, what would he specify as the sample rate to the fft_sink_c(sample_rate=x)? My guess is sample_rate=4e6. Thank you! Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Input Voltage Range of BasicRX board
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 find anything on the Ettus website that has it. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting the contents of a file.
On Wed, 2007-01-17 at 09:22 -0700, Bahn William L Civ USAFA/DFCS wrote: > 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? You can use the gr.file_source block to turn a binary file into a stream of values that can be connected to further blocks. This could be raw input to the USRP, or could be preprocessed by other blocks in a flow graph. The gr.file_source block takes three parameters in it's constructor: itemsize - the length in bytes for an individual data item in the file filename - pathname of the file to open repeat - if true, loop to beginning of file when EOF if false, end when the file read is complete Other than the itemsize value, the actual format of the data in the file must correspond to the binary format of the data type expected by the block(s) that will be connected to the file_source. So if you have a sequence of short integers (16 bit), you can follow the file_source block with any block that takes shorts as an input (typically their name would have _s at the end.) Shorts are stored 'native-endian', that is, the file must have the low byte/high byte order the same as the native format of the machine reading the file. For x86 machines, this is little-endian, or low byte first. You can use GNU radio blocks to create files in the proper format by implementing a flow graph that ends in a gr.file_sink, and then use the output files later as input to something else. It's a very common testing technique. By the way, there is no notion of sample rate stored with the file; GNU radio will process the samples as fast as can be read from disk. So if you need to emulate a particular real-time data rate, you should follow your gr.file_source with a gr.throttle block. This won't be necessary if you have some other rate-limiting block in your flow graph, such as the USRP itself. There are several examples of gr.file_source use in the examples directory under python/usrp (you can grep for file_source to see them). Conceivably, if your waveform data is already in the right format, you could just use a gr.file_source and a usrp.sink_c to do what you were originally asking above. -- Johnathan Corgan, AE6HO Corgan Enterprises LLC [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Transmitting the contents of a file.
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 appreciated. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] x86_64 path proposal
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 lib32/python2.4/site-packages, but it depends on path ordering to do that). Despite the fact that this solution works, I do not think it is "correct". No python application distributed by Fedora is split between lib and lib64. Packages are either installed in lib or lib64. The only time packages appare to be split between the two folders is when both the i386 and x86_64 version is installed. From what I know, SuSE also install x86_64 python programs only in lib64. I therefore think the correct solution would be to install everything either in lib64 or in lib. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PlayStation 3
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 OpenEmbedded. Currently, I have the configure script running to the point it starts looking for cppunit. It fials there. I suspect some hacking at the OE recipe for cppunit may be required in order for the GNU Radio configure script to find it. Now I will demonstrate my lack of understanding of GNU Radio :) I suspect cppunit generates the checks used by the make check step of the build instructions. Since this is a cross build, non of the executables will actually run on the build system. I should be able to make the test programs, but they would need to run on the target system. While it should be possible to work out the cppunit problem I have, in the short term, is there a way to disable the need for cppunit? If anyone is seriously interested in building GNU Radio with OE, I'd be glad to help get you started. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
