[Discuss-gnuradio] Information Request
Dear Sir, Dear Madam, I am RF design Engineer and I have a Question about the OpenBTS Project. Does it support the Frequency Hopping or not? Sincerely yours, Chaouki _ Consultez vos emails Orange, Gmail, Yahoo!, Free ... directement depuis HOTMAIL ! http://www.windowslive.fr/hotmail/agregation/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Progress (NOT!) on Sheeva Plug Gnu Radio
On 04/08/2010 12:55 AM, Marcus D. Leech wrote: I managed to get GRC up. But when I try to run an application that uses anything graphic, it segfaults, and dumps core, from deep within libdricore.so -- related to OpenGL, I think? So, rip out the GUI stuff. Use my 4-channel audio-type SID receiver without any GUI goop: Continuous aOaOaOaOaO until I interrupt it. The audio_to_file.py example seems to work, though :-) Do you think this would work as a remote data collector (USRP + plug) feeding data over the network to a central PC? That might be useful since it reduces the cost of the receiver nodes. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Overrun Underrun False packets issues on Gnuradio using Beagle Board
On 04/08/2010 12:07 AM, Jeannette Nounagnon wrote:
Hello,
I have a Beagle Board running Gnuradio(3.2.1). I copied the
gnuradio-examples folder from Gnuradio (3.2.2) on the Beagle Board (BB).
When I run the usrp_benchmark_usb, I get a maximum throughput of
4MB/sec, instead of 32MB/sec on my regular Linux desktop.
Here is my problem: On the Beagle Board, I am getting lots of dropped
packets, most false packets, u0 and uU when running benchmark_tx/rx, and
tunnel.py.
My first assumption is that I have a USB bottleneck. Am I correct?
Yes. I'm not sure exactly where the bottleneck is, but I suspect the USB
drivers for the OMAP3 have not been optimized for speed.
I have tried to resolve these problems using a few options so far:
Option 1. Reducing the rate (I modified the gnuradio examples files
accordingly), so I am pretty sure I am reducing the rate of
transmission. [The verbose statements for Requested bit rate and Actual
bitrate are the same]. That did not resolve my problems. Why?
Benchmark_{tx,rx} add signal processing right? I would run oprofile and
see what signal processing block is using most of the CPU time. I
suspect that rewriting the signall processing in assembler using NEON
will help a great deal.
Finally, I'd point out that beagleboard.org is a mentoring organization
for Google Summer of Code. The proposal deadline is sometime tomorrow.
We'd be glad to consider a proposal based on getting this working really
well on the Beagle Board.
Philip
Option 2. Changing buffer size. I am trying to tweak the buffer size(by
modifying fusb_block_size and nblocks) , but I do not know how to check
that the change actually occured in realtime.
(a) Where can I find the real value of the realtime buffer size so I can
print it in verbose. I tried to trace it down, but eventually hit a wall.
(b) How do you think I can change the buffer size and rate in order to
satisfy a maximum throughput of 2MB/sec and still get reliable data?
(c) I know that buffer size is B*N, where B is a multiple of 512 bytes.
I also know that a large N can cause latency, but I want to disregard
any latency issues for now.
Will I resolve anything by changing B and N? I have attempted a few
combinations of B, N and rate, still no solutions.
Any suggestions to resolve these issues are welcome.
Thanks,
Jeannette
___
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] Progress (NOT!) on Sheeva Plug Gnu Radio
On 04/08/2010 07:50 AM, Philip Balister wrote: On 04/08/2010 12:55 AM, Marcus D. Leech wrote: I managed to get GRC up. But when I try to run an application that uses anything graphic, it segfaults, and dumps core, from deep within libdricore.so -- related to OpenGL, I think? So, rip out the GUI stuff. Use my 4-channel audio-type SID receiver without any GUI goop: Continuous aOaOaOaOaO until I interrupt it. The audio_to_file.py example seems to work, though :-) Do you think this would work as a remote data collector (USRP + plug) feeding data over the network to a central PC? That might be useful since it reduces the cost of the receiver nodes. Philip Too early to tell. Apart from the above noted performance issues, it seems deeply-broken on this platform as well. Further testing last night, after I started ripping functionality out of my flow-graph until I got the aO down to a dull roar left me puzzled. -- 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] Progress (NOT!) on Sheeva Plug Gnu Radio
On 04/08/2010 08:23 AM, Marcus D. Leech wrote: On 04/08/2010 07:50 AM, Philip Balister wrote: On 04/08/2010 12:55 AM, Marcus D. Leech wrote: I managed to get GRC up. But when I try to run an application that uses anything graphic, it segfaults, and dumps core, from deep within libdricore.so -- related to OpenGL, I think? So, rip out the GUI stuff. Use my 4-channel audio-type SID receiver without any GUI goop: Continuous aOaOaOaOaO until I interrupt it. The audio_to_file.py example seems to work, though :-) Do you think this would work as a remote data collector (USRP + plug) feeding data over the network to a central PC? That might be useful since it reduces the cost of the receiver nodes. Philip Too early to tell. Apart from the above noted performance issues, it seems deeply-broken on this platform as well. Further testing last night, after I started ripping functionality out of my flow-graph until I got the aO down to a dull roar left me puzzled. If there is any floating point, I suspect it won't work since FP is emulated on the plug. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc
Hi, So, if i am setting interpolation rate 16 at transmitter side(tx_samples.cc), according to the equation the program is sampling at Sampling rate = 400/16 = 25M samples/sec. but, I am able to receive the data only at the same decimation rate 16(rx_streaming_samples.cc) , for which the program is sampling at Sampling rate =100/16 =6.25M samples/sec But for me to transmit and receive data i have to send and receive at 25M samples /sec right ?? if i try to do that i.e., at receiver side samp rate = 100/4 = 25M samples /sec I don't receive at all ...? everything boils down to one question ? the sampling rate what we are talking here is the sampling rate at which the samples have been sampled before sending to RF as discussed in COMMUNICATION THEORY (following the Nyquist Criteria) or the sampling rate calculated to find the allowed no.of samples/sec the ETHERNET can take to connect the host to USRP2. but inside the sampling rate is different ? As i am dealing with RF communication i need to know exactly what sampling rate the USRP2 is sampling the data and sending over the air ? Thanks KRISHNA S --- On Wed, 7/4/10, Per Zetterberg per.zetterb...@ee.kth.se wrote: From: Per Zetterberg per.zetterb...@ee.kth.se Subject: Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc To: Krishna S krishna2...@yahoo.com Cc: gnu discuss-gnuradio@gnu.org Date: Wednesday, 7 April, 2010, 7:52 AM Krishna S wrote: Hi, i am trying to calculate at what sampling rate does the tx_sampless.cc and rx_streaming samples.cc are sending the data (file). from 1 USRP2 to another USRP2. i am setting interpolation as 16 at transmitter side (tx_samples.cc) and decimation rate of 16 at receiver side (rx_streaming_samples.cc) according to formula what i have learnt from WEB is Tx Side : Sampling Rate = DAC rate/ Interpolation rate; Rx Side : Sampling Rate = ADC rate/ Decimation rate; are the above equation are correct for determining the sampling rate Thank You Regards KRISHNA S Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://in.rd.yahoo.com/tagline_ie8_new/*http://downloads.yahoo.com/in/internetexplorer/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Yes, it is the sample-rate on the host-side. DAC rate and ADC rate is 100MHz. BR/ Per Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SHF spectrum alanlyser
On 04/02/2010 04:42 AM, Andrew Rich wrote: Hello I am interested in scanning from 1000 MHz to 1200 MHz Can the USRP and gnu radio down convert and show me a spectrum ? Second question. Can the USRP be used to sweep filters ? Andrew You can use the USRP as a spectrum analyzer, but you'll need to keep in mind how it is different from a standard spectrum analyzer. First, it does not sweep. It will take snapshots of the spectrum up to 8 MHz wide on the USRP1 (25 MHz on the USRP2). If you need a wider picture than that you will need to step the center frequency. The amplitude is also not calibrated to the degree that an expensive analyzer would be. Sweeping filters could probably be done, but it is not that common of an application for us. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on receiver tuning issue
Thank you so much Johnathan. Is that means the signal is converted before ADC? I'm quite confused about how the FPGA configuration connect with host code. The FPGA bitstream is loaded by usrp.source_c or usrp.source_s. Where is the FPGA bitstream loaded into? How does the usrp source class load the FPGA bitstream? Thanks, Yan - Original Message - From: Johnathan Corgan jcor...@corganenterprises.com Date: Tuesday, April 6, 2010 11:32 pm Subject: Re: [Discuss-gnuradio] Questions on DDC in gr-sounder project To: Yan Nie yn...@uwo.ca Cc: discuss-gnuradio@gnu.org On Tue, Apr 6, 2010 at 08:19, Yan Nie yn...@uwo.ca wrote: I'm trying to understand how Digital Down Conversion Implemented in gr-sounder project. The DDC needs to be implemented in FPGA, but there isn't any module in FPGA configuration implementing DDC. How does the receiver in gr-sounder implement Digital Down Conversion? The gr-sounder component does not implement a DDC. The host code issues a tune command to set the center frequency of the analog daughterboard, then the entire baseband bandwidth of the downconverted signal is correlated with the reference PN code at successive lags to get the channel impulse response. Johnathan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc
Krishna, My understanding is that we can regard the sample rate of the DAC and ADC as 100MHz (although the DAC uses internally a larger rate, this is what I have read). Thus the rate at which samples are leaving or entering the RF sections at are 100MHz. The maximum rate at the host side is 25MHz, then that rate is interpolated/decimated in the FPGA to/from the 100MHz. The tx_sampless.cc and rx_streaming_sampless.cc reads and writes from file and therefore 25MHz host sample-rate may not be possible. Thus you should typically use the same interpolation/decimation factor in the transmitter and receiver. BR/ Per Krishna S wrote: Hi, So, if i am setting interpolation rate 16 at transmitter side(tx_samples.cc), according to the equation the program is sampling at Sampling rate = 400/16 = 25M samples/sec. but, I am able to receive the data only at the same decimation rate 16(rx_streaming_samples.cc) , for which the program is sampling at Sampling rate =100/16 =6.25M samples/sec But for me to transmit and receive data i have to send and receive at 25M samples /sec right ?? if i try to do that i.e., at receiver side samp rate = 100/4 = 25M samples /sec I don't receive at all ...? everything boils down to one question ? the sampling rate what we are talking here is the sampling rate at which the samples have been sampled before sending to RF as discussed in COMMUNICATION THEORY (following the Nyquist Criteria) or the sampling rate calculated to find the allowed no.of samples/sec the ETHERNET can take to connect the host to USRP2. but inside the sampling rate is different ? As i am dealing with RF communication i need to know exactly what sampling rate the USRP2 is sampling the data and sending over the air ? Thanks KRISHNA S --- On *Wed, 7/4/10, Per Zetterberg /per.zetterb...@ee.kth.se/* wrote: From: Per Zetterberg per.zetterb...@ee.kth.se Subject: Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc To: Krishna S krishna2...@yahoo.com Cc: gnu discuss-gnuradio@gnu.org Date: Wednesday, 7 April, 2010, 7:52 AM Krishna S wrote: Hi, i am trying to calculate at what sampling rate does the tx_sampless.cc and rx_streaming samples.cc are sending the data (file). from 1 USRP2 to another USRP2. i am setting interpolation as 16 at transmitter side (tx_samples.cc) and decimation rate of 16 at receiver side (rx_streaming_samples.cc) according to formula what i have learnt from WEB is Tx Side : Sampling Rate = DAC rate/ Interpolation rate; Rx Side : Sampling Rate = ADC rate/ Decimation rate; are the above equation are correct for determining the sampling rate Thank You Regards KRISHNA S Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://in.rd.yahoo.com/tagline_ie8_new/*http://downloads.yahoo.com/in/internetexplorer/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org /mc/compose?to=discuss-gnura...@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Yes, it is the sample-rate on the host-side. DAC rate and ADC rate is 100MHz. BR/ Per Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc
As i am dealing with RF communication i need to know exactly what sampling rate the USRP2 is sampling the data and sending over the air ? This has been detailed before on this list, so you can find a more complete explanation by searching the archives. On the transmit side, there are *two* sample rate conversions occurring in the USRP2. The DAC operates internally at 400 Msps, but is configured to interpolate samples presented by the FPGA by a factor of four, so the FPGA must present samples at 100 Msps to the DAC interface bus. This is the DAC rate parameter referred to above. Since it is not possible to provide the USRP2 itself with 100 Msps of data over the GbE communications interface (this would be 3.2 Gbps plus overhead), the USRP2 FPGA implements a configurable interpolation rate digital upconverter, allowing an interpolation rate between 4 and 512. In the case it is configured to interpolate by 4, then the USRP2 will consume samples from the GbE port at 25 Msps, or 800 Gbps + overhead. Since the signal sample format is complex baseband (I and Q in quadrature), the Nyquist criteria allows up to 25 MHz of signal bandwidth to be represented using 25 Msps (not 12.5 MHz, which would be the case for a real signal.) As the interpolation rate in the FPGA is decreased, the USRP2 consumes samples from the GbE at lower and lower rates, and the amount of RF signal bandwidth that can be represented in the sample stream goes down accordingly. In the limit, at an interpolation rate of 512, one would generate a sample stream representing ~183 KHz (100 MHz/512) for further host processing. The receive side is similar, but in the other direction, and there is only one sample rate conversion. The ADC sample rate is 100 Msps, and the configurable digitial downconverter in the USRP2 FPGA filters and decimates the digitized sample stream by a factor between 4 and 512. Thus, at the input to the FPGA, the digitized sample stream is 100 MHz wide, but the DDC reduces and resamples this to between 25 MHz (decimation 4) and ~183 KHz (decimation 512). This is a long way of saying that you should use the same decimation and interpolation rate on the transmitter and receiver to achieve the same sample rate/bandwidth to and from the host PCs. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc
On Thu, Apr 8, 2010 at 08:30, Johnathan Corgan jcor...@corganenterprises.com wrote: In the case it is configured to interpolate by 4, then the USRP2 will consume samples from the GbE port at 25 Msps, or 800 Gbps + overhead. Um, that would be 800 Mbps + overhead. But one could wish :-) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
On 04/07/2010 05:58 PM, Vikram Ragukumar wrote: Matt, Thank you for your email. The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac simple_gemac_wrapper in the fifo_2clock_cascade files. which is instantiated in u2_core. Most of the buffering happens in I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. Does this imply that we can pull out the aeMB core, the 32K RAM and the buffer pool under module u2_core ? You can pull out whatever you want. Start from scratch if you like. But if you take out the processor, you'll need to find some other way to get the peripherals (DAC, clock gen, lsdac, etc.) programmed. To carry out preliminary testing we need to be able to pass data to the gemac and configure appropriate control registers. Could you please suggest what existing modules we could reuse to send data to the gemac ? You're going to need to look at the code. The processor does all that now. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC: Hierarchical Blocks: Several Source- and Sink-Pads
Is GRC able to create Hierarchical Blocks with more than one Sink / Source? I tried to create such a Hierarchical Block in the following way which failed: In a blank GRC-File, I assigned in the Options-Block ID (hierblocktest), Title (hier block test), Generate Options (Hier Block) and Category (Custom). I added two Pad Sources and two Pad Sinks, connected them (connect(source1,sink1), connect(source2,sink2)), generated the flow graph and restarted GRC. To test the block, I added it to a new sheet. The Block is displayed as if it had just one Sink and one Source. I am using GNU Radio Companion 3.3git-696-g1ae689ff. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: Hierarchical Blocks: Several Source- and Sink-Pads
I added the ability to have multiple pads a few months ago. I believe that it works. Make sure that your git clone is recent enough ( im not sure about the version) and make sure that there is not this issue of multiple gnuradio installs (and possibly importing old grc modules). -Josh On Thu, Apr 8, 2010 at 1:41 PM, Christian Rohlfing rohlf...@ti.rwth-aachen.de wrote: Is GRC able to create Hierarchical Blocks with more than one Sink / Source? I tried to create such a Hierarchical Block in the following way which failed: In a blank GRC-File, I assigned in the Options-Block ID (hierblocktest), Title (hier block test), Generate Options (Hier Block) and Category (Custom). I added two Pad Sources and two Pad Sinks, connected them (connect(source1,sink1), connect(source2,sink2)), generated the flow graph and restarted GRC. To test the block, I added it to a new sheet. The Block is displayed as if it had just one Sink and one Source. I am using GNU Radio Companion 3.3git-696-g1ae689ff. ___ 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] Combining daughterboard outputs into a single signal
Is there a simple, cheap way to combine the outputs of two daughterboards into a single signal before sending them on to a power amplifier? I need to generate a slow-hopped frequency hopping system that has nine channels spread out over 200MHz of spectrum from 5260MHz to 5460MHz. What I would like to do is use one XCVR2450 daughterboard to generate the odd-numbered hops and a second one to generate the even-numbered hops. I would keep the hop rate slow enough that each board has sufficient time to tune to its new center frequency. So what I need is a way to combine the two outputs (only one will be active) into a single signal? Is there a simple, cheap, off-the-shelf way to do this? On a related note, what kind of output can I expect from the board that is being tuned and what steps can I take to keep in as low as possible? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Head block in GRC
Hi, I am trying to use the head block in GRC to limit the amount of dat written to a file. Currently I have a very basic configuration set up in GRC with a file source(text data) set to repeat going into the head block going into a throttle to control the sampling rate and going into a file sink. For the head block I have played around with the Number of Items and Vector Size parameters. I have been able to get it to work with some combinations of numbers but they didn't seem to follow any logical pattern. For example if I set the head block input to bytes, Num Items to 50, and Vector Size to 1 I would have thought I would geta 50 byte output file but the file was blank (0 bytes). Any idea on what could be causing this? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- About Vikram's 10/100 mode question, we were wondering if it's a design flaw; i.e. something wrong from the start in the original opencores.org source, or if it's fixable but hasn't been a high priority item given USRP2's high data rate requirements. But then I found this post: http://www.ruby-forum.com/topic/143084 So I guess the former. If there are any hints you can give on what's wrong, we can take a look. Maybe our guys can get it working. Eventually I got completely fed up with the opencores gige core and wrote a completely new one from scratch (the simple_gemac). It only does gigabit, though. Ok. One of the main problems with 10/100/1000 in a spartan is that you need a large number of clocks and the S3 is constrained. My understanding is that it takes 3 BUFGs and one DCM for tri-mode (maybe one more of each for RGMII support but I don't see that) and, between this and other USRP2 needs, you ran into the limit of 8. Is that accurate? Or would 10/100/1000 support would take more than 3... If you just want 10/100 and can live without gigabit, I would suggest doing that, as it will save 1 or 2 clocks. Ok... maybe we can implement both modes if we're careful. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Combining daughterboard outputs into a single signal
On Thu, Apr 8, 2010 at 4:20 PM, Bahn, William L CTR USAF USAFA USAFA/DFCS william.bahn@usafa.edu wrote: Is there a simple, cheap way to combine the outputs of two daughterboards into a single signal before sending them on to a power amplifier? I need to generate a slow-hopped frequency hopping system that has nine channels spread out over 200MHz of spectrum from 5260MHz to 5460MHz. What I would like to do is use one XCVR2450 daughterboard to generate the odd-numbered hops and a second one to generate the even-numbered hops. I would keep the hop rate slow enough that each board has sufficient time to tune to its new center frequency. So what I need is a way to combine the two outputs (only one will be active) into a single signal? Is there a simple, cheap, off-the-shelf way to do this? On a related note, what kind of output can I expect from the board that is being tuned and what steps can I take to keep in as low as possible? Thanks. RF Power combiner? I've used RF splitters fairly often, so while I have no direct experience going the opposite direction, I think there are plenty of companies that will sell what you need. One reference covering some basic questions: http://www.minicircuits.com/pages/pdfs/pwr2-4.pdf Good luck, Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Combining daughterboard outputs into a single signal
On 04/08/2010 04:20 PM, Bahn, William L CTR USAF USAFA USAFA/DFCS wrote: Is there a simple, cheap way to combine the outputs of two daughterboards into a single signal before sending them on to a power amplifier? I need to generate a slow-hopped frequency hopping system that has nine channels spread out over 200MHz of spectrum from 5260MHz to 5460MHz. What I would like to do is use one XCVR2450 daughterboard to generate the odd-numbered hops and a second one to generate the even-numbered hops. I would keep the hop rate slow enough that each board has sufficient time to tune to its new center frequency. So what I need is a way to combine the two outputs (only one will be active) into a single signal? Is there a simple, cheap, off-the-shelf way to do this? On a related note, what kind of output can I expect from the board that is being tuned and what steps can I take to keep in as low as possible? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Plenty of combiners listed here: http://www.minicircuits.com/products/psc_coax_2_0.html Pick one that covers the frequency and power range you want, and provides the isolation you think you'll need. -- 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] Head block in GRC
[...] very basic configuration set up in GRC with a file source(text data) set to repeat going into the head block going into a throttle to control the sampling rate and going into a file sink. For the head block I have played around with the Number of Items and Vector Size parameters. [...] Any idea on what could be causing this? I'm not sure about the internals of these file sources and sinks, but playing around with custom blocks I've found that the function 'message_from_string' does not work properly if the size is set to one byte (e.g. type = byte, vec_size = 1, when size = type*vec_size). No throughput is generated by this, as far as my experience goes. - Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Floating point performance of the Sheeva Plug with FP emulation
I did some measurements this afternoon after I got home from work. Using a naive test loop, I was able to observe roughly 11.5M multiply-accumulates per second. That's not enough for any serious wideband work, but it'll do for simple audio processing. I'm going to muck about with my VLF SID receiver flowgraph and see if I can make it run on the Sheeva without too many aO and with it actually producing some useful output. Cheers -- 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] USRP1 FPGA configuration with 16, 8, 4, 2, and 1-bit quantization options available for test
1) Has this configurable bit-width revision been merged? I could not see the rx_buffer.v modifications in 3.2.2 nor any modifications towards this feature on the host side. 2) Is there any branch doing the required modifications on the host side? I want to decide on whether to revisit my non-working host side modifications that I left several months ago Thanks in advance, Best regards, Nagaraj On Thu, Feb 05, 2009 at 04:47:08PM -0500, Paul Creekmore wrote: * For whoever is interested, I have a branched revision of the USRP1 FPGA * * code ready that supports 16, 8, 4, 2, and 1-bit quantization. The * * Verilog code is available for review in my developer's branch of the GNU * * Radio SVN repository here:* ** * http://gnuradio.org/svn/gnuradio/branches/developers/pcreekmore/quantization/usrp* Thanks Paul! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Progress on Sheeva -- actually got a half-way functional flow-graph working
http://www.sbrac.org/files/audioSIDnoGUI.py http://www.sbrac.org/files/audioSIDnoGUI.grc It can only handle two channels, and it takes 78% of the CPU while doing it, but it does work! -- 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] IQ imbalance...
Hi All I am using a pair of USRP2s, each equipped with a XCVR2450, for transmission over-the-air of an RRC-filtered BPSK signal. The Tx antenna has 3dBi gain, and the Rx antenna has 18 dBi gain. The transmitted signal is at maximum amplitude, with gain set to 30 dB. The clocks on each end of the link are running from the internal oscillators - i.e. the clocks are not locked. At the receive side, using an MM synchroniser and Costas loop, I am able to see a BPSK constellation at the receiver when the Rx Gain setting is 30 dB. The amplitude of the constellation points is around 0.15 in this instance. However, when I increase the Rx Gain beyond 33 dB (in which case the constellation is centered around +/- 0.2 on the scope sink), there seems to be a large IQ amplitude balance, whereby the I signal is much stronger. Indeed, the Q signal disappears entirely when the Rx Gain is above around 36 dB. Is this expected behaviour, and if so, can anyone please explain why this is expected to occur? Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
