[Discuss-gnuradio] run two usrp app on two usrp meet: usrp_standard_common: failed to read FPGA cap register.
Hi all, I run two usrp apps on two usrp, each set the which usrp correctly, but meet usrp_standard_common: failed to read FPGA cap register when I run the second app. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] use of a bulletin board system in lieu of a mailing-list discussion
On Thu, Sep 2, 2010 at 2:14 PM, Matt Ettus m...@ettus.com wrote: On 09/02/2010 10:47 AM, Dan Harasty wrote: Hello, all. OK, I know I'm just the new guy here, and it may be poor form to suggest that a well established forum should change its ways But I find the email-based discussion list VERY inefficient. A lot of people on here seem to use Nabble which provides the bulletin board interface. The mailing list already has search and archive features, as do Nabble and Google. On a more philosophical note, I think a mailing list better encourages participation and community. For example, if everyone only looked at the forum when they had a question that they were hoping to have answered, then there would never be anybody there to answer them. Matt I generally agree with Matt's comments, but I'll add two things: 1.) The Wiki is there to be a more permanent repository of knowledge (i.e. something that's easy to reference vs. the 'conversational' style of the mailing list) 2.) I do see the value of some of the more recent QA type websites. In particular I'll point to stackoverflow (and the related stackexchange set of websites) as an excellent repository of knowledge that excels at building a community. Although, while there are a few questions tagged [gnuradio] on stackoverflow, I don't think it has caught on as a place to ask DSP/comms/gnuradio related programming questions. In any event, I personally still see lots of value in participating the mailing list, but figured I'd throw out the fact that there are already some other options to look for information. Doug -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Adding a FFT to USRP2 design.
Hi, i'm traying to add an FFT module to the the base design of the usrp2. I've found, in my opinion, where is the best place to add it. Between the module dsp_core_rx_old and the module rx_control. If i am right, the dsp_core_rx_old takes the input from the adc and takes out (doing decimation and other stuff) i q in 16 bit, placed together in the output signal sample[31:0]. This the goes in the rx_control module which is , in a semplified way to say it, a rx buffer with some fifos, before all goes in the big buffer pool to be sent with eth. Now, my idea is to place a FFT pipelined module cloked with dsp_clock, between this two modules, so as soon as i have i q i can transform them in ffti fftq, keeping the same dimension of 16 bit (it's a scaled fft, for space design reason). The fft module is a xilinx ip core module, that can, after a calculation latency, stream the result to ouput and in the same time do calculation and get other input sample. So, with this kind of module, i get some 0's in the sample wire during the calculation latency, then the data streams out normally without damaging the whole structure. So i have, in the first simple design, i q that are sent to host as usual, but they are implicity packed in N fft result, [0--0], 0...N-1, 0...N-1, with the numbers of 0's that are placed before the the first good fft result. The first (easy) application is only to send this modified data to host, then if this works i will see how to do some selection on the samples. Is this possible? From simulation, it's easy to see the results, but i can't simulate the whole design of course, so i'm asking if, knowing the flow of data, this is a feasible structure. Another thing i want to ask is, when the usrp2 send data to host, the dsp_rst (a reset) is not activated during the stream, right? It's a continuous flow of sample until it is stopped, if i have understood well. Thank you -- Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Adding a FFT to USRP2 design.
Hi Matteo, It sounds like you are using one of the BLOCK I/O xilinx FFT cores. As you said, the core loads the input i q values, performs computation, then outputs the i q FFT results. And yes, during the load and computation latency periods, there will be the lack of useable output samples. The problem with this, is there may be no way of determining when the first actual fft output sample exists in the sample stream. Unless you put in logic to force some recognizable pattern prior to the fft output. I'm not sure if your blocks of 0's will be easy enough for you to find the first fft output sample, but if it works for you, excellent. Also, due to the non-streaming operation of the block i/o fft core, you will most likely miss blocks of input samples from the ADC. Xilinx has a nice app note on the FFT LogicCores, and in there is timing for all the ffts, including streaming ffts if you require them. Sorry, I am not familiar with the fpga design well enough to advise as to the placement of the fft, or its timimg. Steve Matteo Carucci wrote: Hi, i'm traying to add an FFT module to the the base design of the usrp2. I've found, in my opinion, where is the best place to add it. Between the module dsp_core_rx_old and the module rx_control. If i am right, the dsp_core_rx_old takes the input from the adc and takes out (doing decimation and other stuff) i q in 16 bit, placed together in the output signal sample[31:0]. This the goes in the rx_control module which is , in a semplified way to say it, a rx buffer with some fifos, before all goes in the big buffer pool to be sent with eth. Now, my idea is to place a FFT pipelined module cloked with dsp_clock, between this two modules, so as soon as i have i q i can transform them in ffti fftq, keeping the same dimension of 16 bit (it's a scaled fft, for space design reason). The fft module is a xilinx ip core module, that can, after a calculation latency, stream the result to ouput and in the same time do calculation and get other input sample. So, with this kind of module, i get some 0's in the sample wire during the calculation latency, then the data streams out normally without damaging the whole structure. So i have, in the first simple design, i q that are sent to host as usual, but they are implicity packed in N fft result, [0--0], 0...N-1, 0...N-1, with the numbers of 0's that are placed before the the first good fft result. The first (easy) application is only to send this modified data to host, then if this works i will see how to do some selection on the samples. Is this possible? From simulation, it's easy to see the results, but i can't simulate the whole design of course, so i'm asking if, knowing the flow of data, this is a feasible structure. Another thing i want to ask is, when the usrp2 send data to host, the dsp_rst (a reset) is not activated during the stream, right? It's a continuous flow of sample until it is stopped, if i have understood well. Thank you -- Matteo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Adding-a-FFT-to-USRP2-design.-tp29614711p29614731.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help needed to understand scopesink2
I am using the following code snippet to view a 100kHz sinewave on a virtual oscilloscope: self.interface_rate = 1e9 self.src = gr.sig_source_c(self.interface_rate, gr.GR_SIN_WAVE, 1e3, 1) self.scope = scopesink2.scope_sink_c(panel, sample_rate=self.interface_rate) self.connect(self.src, self.scope) As I increase the frequency of the sine wave to 100kHz, the resolution of the plotted points deteriorates. With a sampling rate of 1MHz and a sine wave frequency of 100kHz, I would expect the time interval between plotted point to always be 1us. However, if I reduce the time-base and select the marker to be Dot Larg I can clearly see that the time-period is not the expected 1us. Please could some one shed some light on why there appears to be a discrepancy; or are my expectation just incorrect. I noticed that the scope base class makes references to message queues; is the discrepancy simply an OS timing issue. Regards, Lukasz -- Roke Manor Research Ltd, Romsey, Hampshire, SO51 0ZN, United Kingdom A Siemens company Registered in England Wales at: Siemens plc, Faraday House, Sir William Siemens Square, Frimley, Camberley, GU16 8QD. Registered No: 267550 Visit our website at www.roke.co.uk The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. Please consider the environment before printing this email ~ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 and external RF tuner
Hi Matt, I have connected the RF tuner that provides (nominal) a gain of 30 dB. So the chain is (SIGGEN)---(TUNER)---(USRP2). The tuner itself introduces spurious signal (below -70dBm). The output spectrum is: a) without tuner (description is above the picture) http://imagebin.ca/view/ZTARvXd.html b) with tuner http://imagebin.ca/view/KOYDSsHI.html Do I need more amplification on the IF signal ? Or does exist another way to obtain a clear spectrum with the injected tone only ? Is it possible that some spurious are due to the downconvertion process ? Regards, Luca 2010/9/2 Matt Ettus m...@ettus.com The BasicRX has no amplification. Its full scale amplitude is +10dBm. The ADC in the USRP2 has a rated SFDR of 88dBFS. That means you may see spurs at levels high as -78dBm equivalent when using a BasicRX. In the plots you sent me, your signal is -50 dBm and the spur is more than 40 dB lower, putting it at better than -90dBm, or more than 12dB better than the spec. That is what you need to expect from a real-world ADC. Normally, if you want to look at a -60dBm signal, you will amplify it a lot before you put it into the ADC. That will make it much stronger than the spurs. This is why boards like the RFX, DBSRX, and WBX all have amplifiers. I suggest amplifying your signal by at least 30dB. Matt On 09/01/2010 06:10 AM, Luca Pascale wrote: Hi all, I am working with a usrp2+BasicRx and an external tuner with a 21.4 MHz IF output and a bandwidth of about 20 MHz. The same setup but with usrp1 (instead of usrp2) it's working well. Now I am injecting a tone at 21.45 MHz (-60 dBm) at the input of the BasicRX and set the usrp2 freq at 21.4MHz (with set_rx_freq() UHD API). The problem is that: a) with sample rate of about 3.125M I have 2 strong spuriouses. The first in the middle of the FFT (FFTDIM/2) and the second one at about the middle of the second half of the FFT b) with a sample rate =3.125 the second spurious disappear but the first at FFTDIM/2 is still present. In both case I can also see the tone at 21.45MHz. To compute the spectrum I use matlab [10*log10(|fftshift(fft(signal*window))|^2)]. Am I doing mistakes or someone have the same problem ? Suggestions ? Thanks in advance Luca ___ 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] Help needed to understand scopesink2
On Fri, Sep 3, 2010 at 5:07 PM, Suleja, Lukasz lukasz.sul...@roke.co.uk wrote: I am using the following code snippet to view a 100kHz sinewave on a virtual oscilloscope: self.interface_rate = 1e9 self.src = gr.sig_source_c(self.interface_rate, gr.GR_SIN_WAVE, 1e3, 1) self.scope = scopesink2.scope_sink_c(panel, sample_rate=self.interface_rate) self.connect(self.src, self.scope) As I increase the frequency of the sine wave to 100kHz, the resolution of the plotted points deteriorates. With a sampling rate of 1MHz and a sine wave frequency of 100kHz, I would expect the time interval between plotted point to always be 1us. However, if I reduce the time-base and select the marker to be Dot Larg I can clearly see that the time-period is not the expected 1us. Please could some one shed some light on why there appears to be a discrepancy; or are my expectation just incorrect. You use sample rate 1e9 = 1 Gsps - I think that's slightly above what is possible on standard PC. Maybe that's just a typo? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Help needed to understand scopesink2
Thanks to Alex for pointing out a mistake in the code snippet, it should read: self.interface_rate = 1e6 # i.e. 1 MS/s -- Roke Manor Research Ltd, Romsey, Hampshire, SO51 0ZN, United Kingdom A Siemens company Registered in England Wales at: Siemens plc, Faraday House, Sir William Siemens Square, Frimley, Camberley, GU16 8QD. Registered No: 267550 Visit our website at www.roke.co.uk The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. Please consider the environment before printing this email ~ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dimension of the y axis using usrp_oscope.py
You'll need to read the datasheet for the ADC. It's a AD9862. From there you'll know the full range. I suspect is south of 3.3v as that's the boards power supply. An easier solution is to use a precision function generator and calibrate. Send in a known signal and see what the graph displays. Change the known signal, rinse and repeat. -William On Thu, Sep 2, 2010 at 5:34 PM, Fabian Steiner r...@fabis-site.net wrote: Hello - It will be completely dependent on your receiver chain. My understanding is that the values you are seeing are the output of the ADC, so you'll need to figure out what the voltages at that point are. Perhaps someone else can be more helpful, but you'll need to do the legwork. What receiver are you using? -William I am using a LFRX board. I know that the usrp's ADC has a resolution of 12bit, but what is the maximum value it can deal with? Unfortunately, I haven't found any information on this issue yet. Looking forward to further pieces of advice. Cheers, Fabian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 and external RF tuner
Well, you haven't really provided enough information here. Assuming that your RF Tuner consists of some sort of frequency conversion and an LO, you should know that you will always have leakage between the LO input into the mixer and the IF output. Perhaps that is what you are seeing? Does your RF Tuner have any sort of filtering? If the spurious signal is on the IF, amplifying it will also amplify the spurious products. ~Jeff On 9/3/2010 11:45 AM, Luca Pascale wrote: Hi Matt, I have connected the RF tuner that provides (nominal) a gain of 30 dB. So the chain is (SIGGEN)---(TUNER)---(USRP2). The tuner itself introduces spurious signal (below -70dBm). The output spectrum is: a) without tuner (description is above the picture) http://imagebin.ca/view/ZTARvXd.html b) with tuner http://imagebin.ca/view/KOYDSsHI.html Do I need more amplification on the IF signal ? Or does exist another way to obtain a clear spectrum with the injected tone only ? Is it possible that some spurious are due to the downconvertion process ? Regards, Luca -- ~Jeffrey Lambert, K1VZX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD host resources and system suggestions
I'm a puzzled by some UHD behavior and wondering if I need a new host system. I'm not doing any signal processing in the host -- just transmitting from a buffer and/or receiving from a buffer. Later, we'll be wanting to do more processing with two USRP2s both transmitting and receiving at the same time and may want 25 Msps in some cases. I've managed to get simultaneous receive threads going for each of two USRP2s, both at 25 Msps (big buffers are good). The GUI still updates, but is a little sluggish. It's fragile, though. If I do much at all with the GUI (sometimes just moving the mouse), recv's start timing out. System Monitor shows no memory pressure and both CPUs at 50-60%. FWIW, I'm running my C++ app via SSH from another machine. Transmitting is worse. Even a solo transmit thread at 25 Msps (plus a thread calling recv_async_msg) causes the GUI to be unusable and I get frequent Us on both the host and the USRP2's serial port, as well as tons of EVENT_CODE_SEQ_ERROR and EVENT_CODE_SEQ_ERROR_IN_BURST messages from recv_async_msg. I can't tell what the CPU utilization is because System Monitor stops updating. 6.25 Msps is better, but I still get a few Us and a bunch of EVENT_CODE_SEQ_ERROR and EVENT_CODE_SEQ_ERROR_IN_BURST messages. System Monitor manages to update and shows CPU utilization of 80% and 55%. Again, I'm only transmitting from a buffer that I fill once up front and send over and over again with no signal processing. I'm specifying recv_buff_size=100e6 and send_buff_size=100e6; net.core.rmem_max and net.core.wmem_max are set to 1. I'm calling uhd::set_thread_priority_safe from each of my threads. I'm using the latest gnuradio and UHD software/firmware/FPGA (the recent release with USRP1 support). I have Ubuntu 10.4 with stock ethernet drivers. I've itemized a few details of the hardware setup below. What systems are you all using for MIMO-like work with USRP2s and UHD? What systems do you recommend or wish you had? Are there other changes I should make to my current system? TIA -Marc Dell DCDO tower manufactured in 2007 Dual-core Xeon 5110 @ 1.60 GHz 2 GB RAM Lots of slots - mix of PCI, PCIe, PCI-X Ethernet 0: USRP2 with DBSRX Onboard 10/100/1000 Ethernet. USRP2 says no flow control and we're getting another PCI Express card. Ethernet 1: network connection D-Link PCI NIC No flow control Ethernet 2: USRP2 with XCVR2450 StarTech.com PCI Express 10/100/1000 Ethernet NIC Ubuntu identifies it as Broadcom NetXtreme BCM5752 USRP2 says it gets WE_TX flow control ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD host resources and system suggestions
Sorry to reply to myself, but we just got the new Ethernet NIC so both USRP2s report WE_TX flow control. Nothing changed. And I have a correction for the types of ethernet cards. The onboard NIC is the Broadcom. Ethernet 2 (and now 3) appear to be Realtek RTL8111/8168B. On Sep 3, 2010, at 3:10 PM, Marc Epard wrote: I'm a puzzled by some UHD behavior and wondering if I need a new host system. I'm not doing any signal processing in the host -- just transmitting from a buffer and/or receiving from a buffer. Later, we'll be wanting to do more processing with two USRP2s both transmitting and receiving at the same time and may want 25 Msps in some cases. I've managed to get simultaneous receive threads going for each of two USRP2s, both at 25 Msps (big buffers are good). The GUI still updates, but is a little sluggish. It's fragile, though. If I do much at all with the GUI (sometimes just moving the mouse), recv's start timing out. System Monitor shows no memory pressure and both CPUs at 50-60%. FWIW, I'm running my C++ app via SSH from another machine. Transmitting is worse. Even a solo transmit thread at 25 Msps (plus a thread calling recv_async_msg) causes the GUI to be unusable and I get frequent Us on both the host and the USRP2's serial port, as well as tons of EVENT_CODE_SEQ_ERROR and EVENT_CODE_SEQ_ERROR_IN_BURST messages from recv_async_msg. I can't tell what the CPU utilization is because System Monitor stops updating. 6.25 Msps is better, but I still get a few Us and a bunch of EVENT_CODE_SEQ_ERROR and EVENT_CODE_SEQ_ERROR_IN_BURST messages. System Monitor manages to update and shows CPU utilization of 80% and 55%. Again, I'm only transmitting from a buffer that I fill once up front and send over and over again with no signal processing. I'm specifying recv_buff_size=100e6 and send_buff_size=100e6; net.core.rmem_max and net.core.wmem_max are set to 1. I'm calling uhd::set_thread_priority_safe from each of my threads. I'm using the latest gnuradio and UHD software/firmware/FPGA (the recent release with USRP1 support). I have Ubuntu 10.4 with stock ethernet drivers. I've itemized a few details of the hardware setup below. What systems are you all using for MIMO-like work with USRP2s and UHD? What systems do you recommend or wish you had? Are there other changes I should make to my current system? TIA -Marc Dell DCDO tower manufactured in 2007 Dual-core Xeon 5110 @ 1.60 GHz 2 GB RAM Lots of slots - mix of PCI, PCIe, PCI-X Ethernet 0: USRP2 with DBSRX Onboard 10/100/1000 Ethernet. USRP2 says no flow control and we're getting another PCI Express card. Ethernet 1: network connection D-Link PCI NIC No flow control Ethernet 2: USRP2 with XCVR2450 StarTech.com PCI Express 10/100/1000 Ethernet NIC Ubuntu identifies it as Broadcom NetXtreme BCM5752 USRP2 says it gets WE_TX flow control ___ 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 host resources and system suggestions
On 09/03/2010 04:52 PM, Marc Epard wrote: Sorry to reply to myself, but we just got the new Ethernet NIC so both USRP2s report WE_TX flow control. Nothing changed. And I have a correction for the types of ethernet cards. The onboard NIC is the Broadcom. Ethernet 2 (and now 3) appear to be Realtek RTL8111/8168B. On Sep 3, 2010, at 3:10 PM, Marc Epard wrote: I'll comment that a 1.6GHz machine that's getting close to 4 years old isn't particularly beefy by todays standards. Certainly not beefy enough to sustain two 25Msps threads without problems. Just the interrupt load alone is rather frightening. The packets used by the USRP2 aren't terribly big, something like 300-500 bytes I think. So, 25e6 / 3e2 = 83Kpackets/second--depending on your NIC, each of those packets could be creating an interrupt! Then you have to actually process the darn things -- copy up to user space, do stuff, and present the result of that stuff either back out to the network, or into your software (FFT display, whatever). To give some perspective. I run my radio astronomy Rx-only stack on a 6-core machine doing stuff that's of the same order of complexity as modern telecom-type signal processing. At 5 or 6MHz bandwidth, the machine is working *really* hard. That's a machine with an AMD Phenom II X6 1090t, running at 3.2GHz/core with 6GB of *fast* memory. [And I suspect a flaky power supply, but that's a topic for another day :-) ]. -- 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] GRC's graphical sinks performance issues
Matt Ettus wrote: On 09/02/2010 07:09 AM, Jack Ott wrote: The strange thing is that when the fft's sample rate is at 25Msps which equals the USRP's bandwidth at a decimation of 4 everything works fine with the regular fft sink yet not with the OpenGL one. However when I increase the fft's sample rate to 50Msps which is 2x the USRP's bandwidth both sinks work fine. What does this mean? I'm really convinced all this is because graphics are rendered strictly through software. Does GRC even support graphics hardware acceleration? how do I configure it? Jack, I think you are missing the point here. There is no need to lie to the program. If you are sending the FFT sink 25 MS/s, then tell it you are sending it 25 MS/s. If you give it a different rate you will have all sorts of other issues, like incorrect frequency scales on the display. If you want to decrease the processor load then reduce the display update rate. If you have unaccelerated OpenGL, then the OpenGL version will be unacceptably slow. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks for pointing that out, I was wondering why the scales were acting up. Anyway, am setting up a fresh OS in a couple of days on a different machine, hopefully then I'll be able to pinpoint where I've gone wrong. Thanks everyone. -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29619104.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Getting my feet wet on the Tx side of the world
OK, so I'm wetting my collective feet (all two of them) in the Tx side of the world, with a comms/telecom application, no less. I'm playing with the OP25 project, which is an open-source initiative to produce tools to deal with the so-called Project 25 digital radio standard that is emerging as the way lots of public-service people talk to each other on their radios. The TX side of the project is still fairly primitive--they have a hand-coded flow-graph that implements an APCO-25 4-level FSK modulator, using an *audio* sink, and then carefully plugging the audio into the guts of a physical radio, right at the FM modulator (for those of you who were around in the old amateur packet radio days, that's the way we used to do 9600BPS packet--bypass the usual FM audio filtering, and plug directly into the FM modulator). So, I decided to adapt what they'd done on the audio side to driving a USRP directly (with an appropriate RF card, naturally). The audio version of their modulator is fairly straightforward. It takes two-bit sequences from a packed-byte stream, and uses them to produce symbols from a simple [1.0, 3.0, -1.0, -3.0] chunks-to-simples conversion. From there, the symbols are run through an RRC filter, then an FM preemphasis filter, then a gain multiplier block, and thence to the audio sink. I have constructed a flow-graph in GRC that I think does pretty-much the same thing, only instead of dumping to the audio port, it has an FM modulator block, and then goes to a USRP sink, with appropriate interpolation specified. My GRC flow-graph is here: http://www.sbrac.org/files/fm4_usrp_modulator.grc APCO-25 runs at a nominal symbol rate of 4800sps, to give 9600BPS, and occupies a nominal 12.5KHz of bandwidth. The rest of it involves the usual suspects of FEC coding, packetizing, etc, etc. I'm just interested in getting the modulator correct at this stage, since the rest of the goo is already partially addressed in the existing OP25 work. I'm not sure that my parameters for the RRC are correct, for one, and exactly what to set the sensitivity parameter to in the the FM modulator (I imagine it's similar to setting the deviation control on an analog FM modulator). Also, I've copied the signal processing chain almost directly from the version of the modulator that dumps to the audio port, so perhaps there are shortcuts I can take to produce a nice APCO-25 4-level FSK signal that are cheaper. -- 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] Flowgraph running in fits and starts
I've got a flow-graph with a throttled random byte source, which is a test input for a modulator: http://www.sbrac.org/files/fm4_test_modulator.grc http://www.sbrac.org/files/fm4_test_modulator.py The source is throttled to the byte rate required to produce the correct number of symbols/second (4800). What I've noticed is that this graph only runs in fits and starts, rather than continuously. I assume this has something to do with the Gnu Radio buffering and internal scheduler. In the case of a real flow-graph, taking real data in at 4800symbols/second, going to a real USRP transmitter, will it still run in fits and starts or will it do the right thing?? I realize that buffering is an important part of Gnu Radio, but how do you actually send low-rate data in something approaching correct real-time? I at first thought this was due to the throttle block, so I replaced it with an external (via a FIFO) source that produced random bytes at a 1200-bytes/second rate (2 bits/symbol), and it behaves exactly the same as a a throttled random source--the graph seems to run in fits and starts. -- 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] Flowgraph running in fits and starts
On Fri, Sep 03, 2010 at 10:09:01PM -0400, Marcus D. Leech wrote: I've got a flow-graph with a throttled random byte source, which is a test input for a modulator: http://www.sbrac.org/files/fm4_test_modulator.grc http://www.sbrac.org/files/fm4_test_modulator.py The source is throttled to the byte rate required to produce the correct number of symbols/second (4800). The throttle block was written so that the GUI elements could be tested without an inherently rate limiting source being in the graph. It is not designed to precisely rate limit anything. For any use other than that, you're asking for trouble. Think about it: what definitely of time to you use? Over what period of time do you average, etc, etc. /*! * \brief throttle flow of samples such that the average rate does not exceed samples_per_sec. * \ingroup misc_blk * * input: one stream of itemsize; output: one stream of itemsize * * N.B. this should only be used in GUI apps where there is no other * rate limiting block. It is not intended nor effective at precisely * controlling the rate of samples. That should be controlled by a * source or sink tied to sample clock. E.g., a USRP or audio card. */ What I've noticed is that this graph only runs in fits and starts, rather than continuously. I assume this has something to do with the Gnu Radio buffering and internal scheduler. In the case of a real flow-graph, taking real data in at 4800symbols/second, going to a real USRP transmitter, will it still run in fits and starts or will it do the right thing?? It will do the right thing, assuming that all blocks do the right thing and compute as much output as they are asked to. I realize that buffering is an important part of Gnu Radio, but how do you actually send low-rate data in something approaching correct real-time? You don't send it at the right rate, you let the sink (or source) handle the timing issues. Note that NONE of GNU Radio has any idea of the actual sample rate. There are some places where sample rates are used (e.g., gr.sig_source), but they are there as a convenience so that people don't have to continually puzzle over normalized frequencies. However, this may give the impression that sample_rate actually means something in the real world, and it doesn't --- with the exception of i/o devices connected to a sample clock. I at first thought this was due to the throttle block, so I replaced it with an external (via a FIFO) source that produced random bytes at a 1200-bytes/second rate (2 bits/symbol), and it behaves exactly the same as a a throttled random source--the graph seems to run in fits and starts. The display may appear to run in fits and starts because the internal decimation rate of the sink may be too high for the throttled data rate that you're sending. It may take a long time to get enough data for the FFT sink to display anything. Or there could be bugs in the sink... E.g., the GL fft sink has at least a bug or two related to the mis-specification of python's '/' operator. If you use integers, 1/3 == 0, but 1.0/3 = . The bug I'm thinking of shows up as a divide by zero in the persistence code when the ftt sink is invoked with its default parameters (sample_rate = 1, fft_rate = 15). There may also be problems with mapping the user provided fft_rate into the decimation factor of the keep_one_in_n block. Not sure about that one, but this is a place where it's possible to ask for ill-specified behavior. E.g., if I say that the fft_rate is 15, and my sample rate is 1, do I expect interpolation by 15??? See Python PEP-238 for background on the divide issue and the use of from __future__ import division to debork the behavior of '/', and possibly help fix the sinks. If you want to see the details of what the scheduler is doing, change #define ENABLE_LOGGING 0 to #define ENABLE_LOGGING 1 at the top of gr_block_executor.cc It will then create a separate ASCII log file for each block. They're named sst-NNN.log. The first line of each log identifies the block. Hope this helps! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On Fri, Sep 03, 2010 at 04:21:53PM -0700, Jack Ott wrote: Matt Ettus wrote: On 09/02/2010 07:09 AM, Jack Ott wrote: The strange thing is that when the fft's sample rate is at 25Msps which equals the USRP's bandwidth at a decimation of 4 everything works fine with the regular fft sink yet not with the OpenGL one. However when I increase the fft's sample rate to 50Msps which is 2x the USRP's bandwidth both sinks work fine. What does this mean? I'm really convinced all this is because graphics are rendered strictly through software. Does GRC even support graphics hardware acceleration? how do I configure it? Jack, I think you are missing the point here. There is no need to lie to the program. If you are sending the FFT sink 25 MS/s, then tell it you are sending it 25 MS/s. If you give it a different rate you will have all sorts of other issues, like incorrect frequency scales on the display. If you want to decrease the processor load then reduce the display update rate. If you have unaccelerated OpenGL, then the OpenGL version will be unacceptably slow. Matt Thanks for pointing that out, I was wondering why the scales were acting up. Anyway, am setting up a fresh OS in a couple of days on a different machine, hopefully then I'll be able to pinpoint where I've gone wrong. Thanks everyone. FWIW, independent of GNU Radio, I've found that OpenGL support in Linux still leaves a lot to be desired in the performance and reliability departments. (Spoken as someone who's recently tried high performance cards from both Nvidia and ATI, trying both the proprietary and open source drivers for each one... on Fedora 13) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in fits and starts
On 09/03/2010 11:52 PM, Eric Blossom wrote: The throttle block was written so that the GUI elements could be tested without an inherently rate limiting source being in the graph. It is not designed to precisely rate limit anything. For any use other than that, you're asking for trouble. Think about it: what definitely of time to you use? Over what period of time do you average, etc, etc. I understand that. See below. It will do the right thing, assuming that all blocks do the right thing and compute as much output as they are asked to. You don't send it at the right rate, you let the sink (or source) handle the timing issues. Note that NONE of GNU Radio has any idea of the actual sample rate. There are some places where sample rates are used (e.g., gr.sig_source), but they are there as a convenience so that people don't have to continually puzzle over normalized frequencies. However, this may give the impression that sample_rate actually means something in the real world, and it doesn't --- with the exception of i/o devices connected to a sample clock. Yes, I get that. The display may appear to run in fits and starts because the internal decimation rate of the sink may be too high for the throttled data rate that you're sending. It may take a long time to get enough data for the FFT sink to display anything. Or there could be bugs in the sink... E.g., the GL fft sink has at least a bug or two related to the mis-specification of python's '/' operator. If you use integers, 1/3 == 0, but 1.0/3 = . The bug I'm thinking of shows up as a divide by zero in the persistence code when the ftt sink is invoked with its default parameters (sample_rate = 1, fft_rate = 15). There may also be problems with mapping the user provided fft_rate into the decimation factor of the keep_one_in_n block. Not sure about that one, but this is a place where it's possible to ask for ill-specified behavior. E.g., if I say that the fft_rate is 15, and my sample rate is 1, do I expect interpolation by 15??? See Python PEP-238 for background on the divide issue and the use of from __future__ import division to debork the behavior of '/', and possibly help fix the sinks. Thought about that, as well. So replaced the graphical FFT sink with a file sink, and set the unbuffered flag. That file fills up in fits and starts'--that is, it spends quite a while with zero bytes in it, then really a lot of bytes, then no more bytes for quite some time, then another lump of bytes, etc. I confirmred that the producer end of the FIFO was producing bytes at the correct rate. So when I'm sending real data to an actual USRP (f'rexample), the symbols will get clocked out at the right rate, provided that I issue those bits in sufficiently large lumps to prevent the USRP from underrun on transmit. But what about situations where you might have a source of bits that's running in real time (like my little test case with the external FIFO), and you'd like the resulting symbols to be clocked out at something resembling real time? My test case was just a test case, but I can certainly imagine situations where it actually matters. If you want to see the details of what the scheduler is doing, change #define ENABLE_LOGGING 0 to #define ENABLE_LOGGING 1 at the top of gr_block_executor.cc It will then create a separate ASCII log file for each block. They're named sst-NNN.log. The first line of each log identifies the block. Hope this helps! Eric -- 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] GRC's graphical sinks performance issues
On 09/04/2010 12:01 AM, Eric Blossom wrote: FWIW, independent of GNU Radio, I've found that OpenGL support in Linux still leaves a lot to be desired in the performance and reliability departments. (Spoken as someone who's recently tried high performance cards from both Nvidia and ATI, trying both the proprietary and open source drivers for each one... on Fedora 13) Eric I have a system upon which *none* of the Gnu Radio apps that include OpenGL stuff will work at all, producing an almighty core dump from inside some Python gtk2 module. Even when I set LIBGL_ALWAYS_INDIRECT=1. That's for identical F12 installations, Gnu Radio installations, etc, etc. Only difference is the video card. And if I turn off OpenGL, things work. But curiously enough the little OpenGL test app, glxgears, works flawlessly (of course!). -- 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
