[Discuss-gnuradio] tcp/udp source sink?
Does the gnu radio project have a udp/tcp/networking source and sink pair? -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tcp/udp source sink?
Funny enough, I just wrote one on the plane ride into Vegas this week. When I get back to my lab, I'll test its performance over the network (not just using the loopback device and make sure I've got some error cases handled properly. With any luck, I'll get this into the trunk soon. Currently, it's connectionless UDP only. Tom Josh Blum wrote: Does the gnu radio project have a udp/tcp/networking source and sink pair? -Josh ___ 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] tcp/udp source sink?
On Fri, Jan 12, 2007 at 02:23:14PM -0500, Josh Blum wrote:
> Does the gnu radio project have a udp/tcp/networking source and sink
> pair? -Josh
Create the socket(s) in python and/or C++ then pass them to
gr_file_descriptor_{source,sink}
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tcp/udp source sink?
Any change these can be multicast? On 1/12/07, Tom Rondeau <[EMAIL PROTECTED]> wrote: Funny enough, I just wrote one on the plane ride into Vegas this week. When I get back to my lab, I'll test its performance over the network (not just using the loopback device and make sure I've got some error cases handled properly. With any luck, I'll get this into the trunk soon. Currently, it's connectionless UDP only. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] What is the simplest way to get data to/from the USRP
I'm just getting back to this after a few months (gotta love funding issues). Brief recap on what I am trying to do: I am trying to perform some very non-conventional signal processing. To show that our basic approach is viable it is sufficient for us to perform the following tasks: 1) Generate a waveform that we want to transmit. This waveform has data encoded into it. Ideally, the data is just a list of numbers that we want to send to a DAC. We can prepare this well ahead of time. 2) Broadcast the waveform generated in the previous step. 3) Receive the waveform that was broadcast and record it as a time-sampled sequence of numbers that represent the outputs of an ADC. 4) Analyze the data and see if the information we embedded in the waveform is recoverable. This can be done completely off-line via post-processing. The only part that we need GNUradio and/or the USRP for is #2 and #3. -- Task #3: Previously, Eric recommended the following: > If you want to capture data from the front end and put it into a file, > the easiest way is to use gnuradio-examples/python/usrp/usrp_rx_cfile.py This looks very promising for taking care of Task #3. Playing around with it has generated a few questions: 1) What are the legal values of the decimation factor? I see a comment in the code that the minimum factor is 4 and that the default is 16. By experimentation I also observe that integer powers of two up to and including 256 are legal. What is the maximum decimation allowed? Other factors, such as 192, are permitted, but arbitrary values are not. Are there a certain number of most significant bits in the value that can be chosen? 2) What does the FREQ parameter do? It clearly doesn't set the sampling frequency - that appears to be a fixed 64 MSps divided by the decimation value. 3) I see that the -R option allows be to chose which subdevice on the USRP, but how do I choose (or know which one if I can't choose) which input on, say, the Basic-RX board is being used? BTW: I think the duplicated nomenclature is confusing. On the BasicRX daughterboard the two inputs are labeled RX-A and RX-B, so I thought that the -R option was referring to this selection and was wondering how you tell it which daughterboard to pull the signal from. It wasn't until I looked at an unpopulated USRP (since, with the four daughter boards mounted on the USRP, the RX-A and RX-B labels are hidden) and noticed that the daughterboard slots themselves use the same labels that I realized what the -R option is really referring to. 4) I see in the file that the data is stored (by default) as two single precision floating point numbers that represent a complex number. Clearly, then, this is not simply the output of the ADC. What is it? How do I (assuming I can) recover what the time-sequence of values coming out of the ADC were? 5) What are the input tolerances of the BasicRX daughterboard? I have a function generator that I want to use to send a signal into it, but want to be sure that I don't exceed the input range of the board? Also, what is the input impedance? Is it intended to be driven from a 50 ohm source? 6) Perhaps the most important question: Where do I find the answers to the above questions? These all seem like really basic questions about the details of the interface, but I haven't found anyplace that provides this information. -- As far as Task #2: 1) Is there any similar program in GNUradio that does the reverse of usrp_rx_cfile? Namely, takes a file of appropriately formatted time-sequence samples and broadcasts that waveform? One issue I know that I need to deal with is what it means to "broadcast" the waveform that was generated in Task #1. Ideally, at least from a conceptual standpoint, the waveform data would represent the actual output at the antenna so that (assuming 1-bit on-off encoding) the sequence 0010001010 would result in three very sharp chirps of energy being broadcast. Given the need for the USRP to perform up-conversion, I know that this level of control is not possible (not to mention the prohibitive bit rates that would be required). We can live with that, but we want to get as close to that as we can. -- Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gmsk strangeness
'lo all. We are trying to use the USRP with the new gmsk demod block, and are encountering some weirdness. To generate our GMSK signal, we are using an Agilent signal generator. BT=0.35, 125 ksymbols/sec, 2 samples/symbol, with a PN15 as the data source. We load the produced slicer.dat into Matlab and cross-correlate with the known PN15 sequence. Sometimes the output looks good: all our peaks are at 2^15 - 1 = 32767, indicating that all bits are being demodded correctly, as you can see here: http://img472.imageshack.us/img472/2766/fullpeakscb3.jpg Other times, we encounter "half-height" peaks, which go up to 2^14-1 = 16383, indicating that 25% of the bits are being demodded incorrectly. You can see this here: http://img441.imageshack.us/img441/7507/halfpeaksax7.jpg If you zoom in on the previous image, you can see that each xcorr peak actually consists of 2 high points, then a lull of 14 or so, then another high point. This pattern is always the same when the half-height phenomena is observed: http://img168.imageshack.us/img168/7657/halfpeakszoomeduy7.jpg Any idea what might be going on, or how to debug this? -Steven ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gmsk transmit woes
Hello, I'm having a curious problem that I'd like to figure out. What I'm trying to do is to have two different gmsk packet sources, modulate them on different frequencies, add these signals together and then transmit them simultaneously (with their destination being two separate usrp's tuned to the different frequencies). Here is a sketch of what I have so far: self.packet_transmitter1 = blks.gmsk2_mod_pkts(...) self.packet_transmitter2 = blks.gmsk2_mod_pkts(...) self.chan_filt1 = gr.freq_xlating_fir_filter_ccc(...freq1...) self.chan_filt2 = gr.freq_xlating_fir_filter_ccc(...freq2...) self.adder = gr.add_cc() fg.connect(self.packet_transmitter1, self.chan_filt1, (self.adder,0)) fg.connect(self.packet_transmitter2, self.chan_filt2, (self.adder,1)) fg.connect(self.adder, self.amp, self.u) for now, I have both the xlating_fir's as all-pass filters, just to take advantage of their frequency translating. The strange problem is that when I run the script, it stalls; the code gets 2 dots into the transmitting and then stops, and I have to ctrl-z (ctrl-c doesn't even work). What is possibly going wrong? Thanks! -Michael Ford- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gmsk strangeness
Other times, we encounter "half-height" peaks, which go up to 2^14-1 = 16383, indicating that 25% of the bits are being demodded incorrectly. Can you get phase information from those samples? If you plot IQ in your unit circle at 1 sample per symbol, do you get a correctly equalized waveform? Any idea what might be going on, or how to debug this? Could you post your samples? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gmsk transmit woes
Michael Ford wrote: Hello, I'm having a curious problem that I'd like to figure out. What I'm trying to do is to have two different gmsk packet sources, modulate them on different frequencies, add these signals together and then transmit them simultaneously (with their destination being two separate usrp's tuned to the different frequencies). Here is a sketch of what I have so far: self.packet_transmitter1 = blks.gmsk2_mod_pkts(...) self.packet_transmitter2 = blks.gmsk2_mod_pkts(...) self.chan_filt1 = gr.freq_xlating_fir_filter_ccc(...freq1...) self.chan_filt2 = gr.freq_xlating_fir_filter_ccc (...freq2...) self.adder = gr.add_cc() fg.connect(self.packet_transmitter1, self.chan_filt1, (self.adder,0)) fg.connect(self.packet_transmitter2, self.chan_filt2, (self.adder,1)) fg.connect(self.adder , self.amp, self.u) for now, I have both the xlating_fir's as all-pass filters, just to take advantage of their frequency translating. The strange problem is that when I run the script, it stalls; the code gets 2 dots into the transmitting and then stops, and I have to ctrl-z (ctrl-c doesn't even work). What is possibly going wrong? Thanks! -Michael Ford- Michael, Take a look at my reply to "up-conversion weirdness" on Oct. 27, 2006. It seems like this is the same problem due to incorrect sampling rates. Hopefully, this will help. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] IMPORTANT: manual intervention needed before updating trunk
Hi, Before you update trunk, please do either: rm gnuradio-core/src/lib/swig/gnuradio_swig_python.py or make clean This is required because a piece of machine generated code (gnuradio_swig_python.py) has be replaced with a hand-written version. If you don't get rid of the old one, the update will complain, and fail to get the latest code. More info in the next message about why all this took place. Sorry for the inconvenience, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SWIG compilation speedup!
I've just checked code into the trunk that speeds up compilation of
the swig generated code, as well as reducing the number of
dependencies for each piece.
-r4255 refactors gnuradio_swig_python.{cc,py} into 5 separate .so's
These correspond to the runtime, general, filter and io directories,
and also includes a new directory, gengen. gengen contains that part
of general that was machine generated. This split is arbitrary, but
was useful for getting size of the swig generated glue code for
general down to about 2MB.
In addition, the swig glue is now compiled with -g1 -O1 instead of
-g -O2. With this change all the swig code now compiles in about 60%
of the time that it used to take.
Packagers, please note that there are now 5 SWIG generated .so's and
.py's in gnuradio-core that replace the previous 1
(gnuradio_swig_python.{so,py})
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG compilation speedup!
On Saturday 13 January 2007 15:05, Eric Blossom wrote:
> I've just checked code into the trunk that speeds up compilation of
> the swig generated code, as well as reducing the number of
> dependencies for each piece.
>
> -r4255 refactors gnuradio_swig_python.{cc,py} into 5 separate .so's
> These correspond to the runtime, general, filter and io directories,
> and also includes a new directory, gengen. gengen contains that part
> of general that was machine generated. This split is arbitrary, but
> was useful for getting size of the swig generated glue code for
> general down to about 2MB.
>
> In addition, the swig glue is now compiled with -g1 -O1 instead of
> -g -O2. With this change all the swig code now compiles in about 60%
> of the time that it used to take.
>
>
> Packagers, please note that there are now 5 SWIG generated .so's and
> .py's in gnuradio-core that replace the previous 1
> (gnuradio_swig_python.{so,py})
>
What are the issues with the compile time? This topic came up previously in
discussions which determined that documentation will nolonger be generated by
default due to build time.
I can't see the point for doing so. I don't care if its takes me 15 minutes or
30 minutes to compile all GNU Radio.
Compilation time saved will now be spend waiting for the download?
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG compilation speedup!
On Sat, 2007-01-13 at 16:12 +1030, Berndt Josef Wulf wrote: > I can't see the point for doing so. I don't care if its takes me 15 minutes > or > 30 minutes to compile all GNU Radio. The biggest improvement isn't the compile time, it's the fact that the memory working set for g++ when compiling the previous gnuradio_swig_python.cc file was 650 MB. This would cause massive swap thrashing on machines with say, 512 MB of RAM, or less, and drive the compilation time up to potentially hours. I just tested the working set size and it comes up to 370 MB now. In addition, the break up reduces the coupling of the different parts of GR, so changes in (many) header files no longer trigger a complete recompile. For developers, we're doing this all day long, so its a major time saver. > Compilation time saved will now be spend waiting for the download? ? -- Johnathan Corgan, AE6HO Corgan Enterprises LLC [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG compilation speedup!
Berndt Josef Wulf wrote: I can't see the point for doing so. I don't care if its takes me 15 minutes or 30 minutes to compile all GNU Radio. Maybe we can add a special option to slow down compiling for you! :) ./configure --enable-slow-compiling Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
