Re: [Discuss-gnuradio] gr_remez insufficient extremals
Hi Bernardo, I'm pretty sure the filter code hasn't changed too much since 3.2.2. However, I'm surprised it worked before: Your FM demodulator requires a pretty steep filter (the transition width is less than 0.005 normalised to the sampling frequency). I only had a quick peek, but since your decimation in the FM demod is 1, you could use a frequency demod instead and couple it with your own (custom) filter. The gr_remez code is a bit unstable in this respect. You normally have to fiddle around with the parameters until you get a good filter, and the FM demod block doesn't give you enough knobs. MB On Mon, Feb 28, 2011 at 11:25:54AM -0300, Bernardo Guadagnin Gonçalves wrote: > Hello, > > > Until last week I was using the Gnu Radio 3.2.2 (which is ready for use in > ubuntu), then I decided to try the latest version (v3.3.1git-147-g5a23954a). > The flowgraph was working perfectly. It's for "in" GRC simulation only. I know > it's very simple and the 38kHz recovery (at the receiver) is not the > recommended way. > > > Flowgraph: http://dl.dropbox.com/u/8898915/FMstereotxrx2.grc > > .Wav for simulation: http://dl.dropbox.com/u/8898915/sine4k.wav > > > The messages that are now shown are: > > > Showing: "/home/mula/Dropbox/Public/FMstereotxrx2.grc" > > > Generating: "/home/mula/Dropbox/Public/top_block.py" > > > Executing: "/home/mula/Dropbox/Public/top_block.py" > > > gr_remez: insufficient extremals -- cannot continue > > Traceback (most recent call last): > > File "/home/mula/Dropbox/Public/top_block.py", line 361, in > > tb = top_block() > > File "/home/mula/Dropbox/Public/top_block.py", line 193, in __init__ > > tau=tau, > > File > "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/fm_demod.py", > line 65, in __init__ > > 60) # Stopband attenuation > > File "/usr/local/lib/python2.6/dist-packages/gnuradio/optfir.py", line 53, > in > low_pass > > taps = gr.remez (n + nextra_taps, fo, ao, w, "bandpass") > > File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/ > gnuradio_swig_py_general.py", line 432, in remez > > return _gnuradio_swig_py_general.remez(*args, **kwargs) > > RuntimeError: gr_remez: insufficient extremals -- cannot continue > > > >>> Done > > > Thanks! > > > Regards, > Bernardo > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpQ74dJog86Z.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sensitivity in fm
How should i interpret sensitivity parameter in fm modulator block in grc? How does it effect modulation characteristics? If you have any opinion or offer please write.Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sensitivity in fm
2011/3/1 ömer günay : > How should i interpret sensitivity parameter in fm modulator block in grc? > How does it effect modulation characteristics? If you have any opinion or > offer please write.Thanks. It corresponds to the maximum deviation, see gnuradio-core/src/python/gnuradio/blks2impl/nbfm_tx.py Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Josh, Thanks a lot for the explanation. When you say 90 packets, I assume that you mean UDP packets (which contain samples). Given the default MTU (1500-8-20)B and 2 samples per symbol as well as 4B per sample, for BPSK or GMSK, 90 packets of samples correspond to 90*1472/(2*4*8)=2070B of user data. If I use 1500B per user packet, that's less than 2 packets. For 700 UDP packets, that's about 10 user packets. This actually explains what I observed, after about 10 user packets, my transmission stopped. According to you, the host blocked first. However, it seemed that USRP didn't send back update packets for some reason--which is unusual. So it's likely timeout was called. To help my understanding what caused the above behavior, would you please spend little time answering the following questions? (1) Which parameter (*ups_per_fifo or **ups_per_sec*) corresponds to the above control parameter here (90 transmission packets and 700 packets update)? (2) How is the update packet generated on USRP? (3) In normal cases, when the host transmits a packet, does it specify a transmission time for USRP? If so, it must get the clock of USRP first and then leave some margin, this introduce some time overhead; if not, does the USRP send whatever it receives immediately? (4) What's the content of the short update packet? Andrew On 02/28/2011 05:58 PM, Josh Blum wrote: A brief description on the flow control implementation: The flow control is only used on the transmit size to throttle the host calls to send(). Update packets are received by the host every 90 transmitted packets. If the host does not get an update packet after about 700 packets, the calls to send will block until the an update packet arrives or timeout. This does not incur any overhead on receive. Update packets are small, have their own dedicated udp port, and arrive infrequently. The overhead on the transmit side is a check of the flow control condition per packet. Which looks like this: return seq_type(_last_seq_out -_last_seq_ack)< _max_seqs_out; -josh On 02/28/2011 02:42 PM, Feng Andrew Ge wrote: Marc, Unfortunately I don't much experience with Ethernet pause-frame flow control. For my applications, sending is not an issue since we don't send high data rates; we are more concerned at the receiver side, particularly its latency (which is related to CPU consumption too.) Andrew On 02/28/2011 05:19 PM, Marc Epard wrote: On Feb 28, 2011, at 3:54 PM, Feng Andrew Ge wrote: Josh, I haven't found time to try what you suggested yet; however, it would be nice that the user has the option to choose host-side flow control. In principle, I don't fully trust host-side flow control simply because there is too much uncertainty in a general-purpose processor (determined by both its hardware architecture and OS). Andrew (We should probably move this to one of the public lists.) Andrew, How much experience do you have with Ethernet pause-frame flow control? It caused us a bunch of problems and judging by the lists over the last 8 months or so, it creates huge customer support problems. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [USRP-users] UHD Announcement - February 25rd 2011
On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum wrote:
> Hello list,
>
> In preparation for the coming gnuradio release, and the cut-over from
> next to master, changes have been pushed to both the uhd.git master
> branch and the gnuradio.git next branch.
I'm getting the following timeouts after the update. I presume this has
something to do with buffering since it always occurs at the same packet
number - code change at end. Same result on e100 and rlt NIC's.
[ttsou@fischer examples]$ ./tx_timed_samples --secs 4 --nsamps 40 --rate
400e3 --dilv --spp 864
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_003.20110226000831.77641c6
Creating the usrp device with: ...
Current recv sock buff size: 5000 bytes
mboard0 MIMO master
Using Device: Single USRP:
Device: USRP2/N Series device
Mboard 0: USRP-N210 mboard
RX DSP 0: USRP-N210 ddc0
RX Channel: 0
RX Dboard: USRP-N210 dboard (rx unit)
RX Subdev: Unknown - Unknown (0x)
TX DSP 0: USRP-N210 duc0
TX Channel: 0
TX Dboard: USRP-N210 dboard (tx unit)
TX Subdev: Basic TX (0x) - AB
Setting TX Rate: 0.40 Msps...
Actual TX Rate: 0.40 Msps...
Setting TX Freq: 0.00 Mhz...
Actual TX Freq: 0.00 Mhz...
Setting device timestamp to 0...
Send timeout... Sent 362 samples of packet 237
Send timeout... Sent 0 samples of packet 238
Send timeout... Sent 0 samples of packet 239
Send timeout... Sent 0 samples of packet 240
Send timeout... Sent 0 samples of packet 241
...
Thomas
---
host/examples/tx_timed_samples.cpp |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/host/examples/tx_timed_samples.cpp
b/host/examples/tx_timed_samples.cpp
index f10d7e4..1f87ae3 100644
--- a/host/examples/tx_timed_samples.cpp
+++ b/host/examples/tx_timed_samples.cpp
@@ -106,7 +106,8 @@ int UHD_SAFE_MAIN(int argc, char *argv[]){
//send will backup into the host this many seconds before sending:
seconds_in_future + 0.1 //timeout (delay before transmit + padding)
);
-if (num_tx_samps < samps_to_send) std::cout << "Send timeout..." <<
std::endl;
+if (num_tx_samps < samps_to_send)
+std::cout << "Send timeout... Sent " << num_tx_samps << " samples
of packet " << i << std::endl;
if(verbose) std::cout << std::endl << boost::format("Sent %d samples")
% num_tx_samps << std::endl;
}
--
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_remez insufficient extremals
Thanks Martin, Thanks for the idea... and, yes, 1kHz for audio stop isn't a good idea. I've reinstalled the 3.2.2 and it really works fine. Anyway, I'll be trying to do a filter as you recommended. Thanks! Bernardo On Tue, Mar 1, 2011 at 5:54 AM, Martin Braun wrote: > Hi Bernardo, > > I'm pretty sure the filter code hasn't changed too much since 3.2.2. > However, I'm surprised it worked before: Your FM demodulator requires a > pretty steep filter (the transition width is less than 0.005 normalised > to the sampling frequency). I only had a quick peek, but since your > decimation in the FM demod is 1, you could use a frequency demod instead > and couple it with your own (custom) filter. > The gr_remez code is a bit unstable in this respect. You normally have > to fiddle around with the parameters until you get a good filter, and > the FM demod block doesn't give you enough knobs. > > MB > > > On Mon, Feb 28, 2011 at 11:25:54AM -0300, Bernardo Guadagnin Gonçalves > wrote: > > Hello, > > > > > > Until last week I was using the Gnu Radio 3.2.2 (which is ready for use > in > > ubuntu), then I decided to try the latest version > (v3.3.1git-147-g5a23954a). > > The flowgraph was working perfectly. It's for "in" GRC simulation only. I > know > > it's very simple and the 38kHz recovery (at the receiver) is not the > > recommended way. > > > > > > Flowgraph: http://dl.dropbox.com/u/8898915/FMstereotxrx2.grc > > > > .Wav for simulation: http://dl.dropbox.com/u/8898915/sine4k.wav > > > > > > The messages that are now shown are: > > > > > > Showing: "/home/mula/Dropbox/Public/FMstereotxrx2.grc" > > > > > > Generating: "/home/mula/Dropbox/Public/top_block.py" > > > > > > Executing: "/home/mula/Dropbox/Public/top_block.py" > > > > > > gr_remez: insufficient extremals -- cannot continue > > > > Traceback (most recent call last): > > > > File "/home/mula/Dropbox/Public/top_block.py", line 361, in > > > > tb = top_block() > > > > File "/home/mula/Dropbox/Public/top_block.py", line 193, in __init__ > > > > tau=tau, > > > > File > "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/fm_demod.py", > > line 65, in __init__ > > > > 60) # Stopband attenuation > > > > File "/usr/local/lib/python2.6/dist-packages/gnuradio/optfir.py", line > 53, in > > low_pass > > > > taps = gr.remez (n + nextra_taps, fo, ao, w, "bandpass") > > > > File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/ > > gnuradio_swig_py_general.py", line 432, in remez > > > > return _gnuradio_swig_py_general.remez(*args, **kwargs) > > > > RuntimeError: gr_remez: insufficient extremals -- cannot continue > > > > > > >>> Done > > > > > > Thanks! > > > > > > Regards, > > Bernardo > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > > ___ > 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: UHD Announcement - February 25rd 2011
> Thanks a lot for the explanation. > To explain your observations for the curious: Prior to the fix, a recv buffer would be lost to the transport layer on each timeout (thanks to an optimization I made earlier). So, for every 100ms window (the default timeout) that did not have at least 90 packets transmitted. A receive buffer was lost. After 32 timeouts, there were no more available buffers and the flow control throttled back. -Josh answers below: > When you say 90 packets, I assume that you mean UDP packets (which > contain samples). Given the default MTU (1500-8-20)B and 2 samples per > symbol as well as 4B per sample, for BPSK or GMSK, 90 packets of samples > correspond to 90*1472/(2*4*8)=2070B of user data. If I use 1500B per > user packet, that's less than 2 packets. For 700 UDP packets, that's > about 10 user packets. This actually explains what I observed, after > about 10 user packets, my transmission stopped. According to you, the > host blocked first. However, it seemed that USRP didn't send back update > packets for some reason--which is unusual. So it's likely timeout was > called. To help my understanding what caused the above behavior, would > you please spend little time answering the following questions? > > (1) Which parameter (*ups_per_fifo or **ups_per_sec*) corresponds to the > above control parameter here (90 transmission packets and 700 packets > update)? (2) How is the update packet generated on USRP? (3) In normal > cases, when the host transmits a packet, does it specify a transmission > time for USRP? If so, it must get the clock of USRP first and then leave > some margin, this introduce some time overhead; if not, does the USRP > send whatever it receives immediately? (4) What's the content of the > short update packet? > 1) ups_per_fifo 2) it counts the number of transmitted packets, and sends an update packet every nth packet (default n = 90) 3) a transmission time is optional, when not specified the send is immediate 4) the sequence of the last transmitted packet > Andrew > > On 02/28/2011 05:58 PM, Josh Blum wrote: >> A brief description on the flow control implementation: >> >> The flow control is only used on the transmit size to throttle the host >> calls to send(). Update packets are received by the host every 90 >> transmitted packets. If the host does not get an update packet after >> about 700 packets, the calls to send will block until the an update >> packet arrives or timeout. >> >> This does not incur any overhead on receive. Update packets are small, >> have their own dedicated udp port, and arrive infrequently. The overhead >> on the transmit side is a check of the flow control condition per >> packet. Which looks like this: >> return seq_type(_last_seq_out -_last_seq_ack)< _max_seqs_out; >> >> -josh >> >> On 02/28/2011 02:42 PM, Feng Andrew Ge wrote: >>> Marc, >>> >>> Unfortunately I don't much experience with Ethernet pause-frame flow >>> control. For my applications, sending is not an issue since we don't >>> send high data rates; we are more concerned at the receiver side, >>> particularly its latency (which is related to CPU consumption too.) >>> >>> Andrew >>> >>> >>> On 02/28/2011 05:19 PM, Marc Epard wrote: On Feb 28, 2011, at 3:54 PM, Feng Andrew Ge wrote: > Josh, > > I haven't found time to try what you suggested yet; however, it would > be nice that the user has the option to choose host-side flow > control. In principle, I don't fully trust host-side flow control > simply because there is too much uncertainty in a general-purpose > processor (determined by both its hardware architecture and OS). > > Andrew (We should probably move this to one of the public lists.) Andrew, How much experience do you have with Ethernet pause-frame flow control? It caused us a bunch of problems and judging by the lists over the last 8 months or so, it creates huge customer support problems. -Marc > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QAM/OFDM modules in GRC
Hi, I just wanted to know if the QAM and OFDM modulation modules provided in GRC are completely functioning or not.As last time I tried they were not ready. If yes, which version of GRC has to be used. Thanking you Kind Regards Varun K ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM implementation
Hi, I want to implement OFDM on gnu radio platform. Is it possible to simulate the code provided without using the hardware . Ben told me to use the Benchmark ofdm code. I wanted to know whether there is some documentation for it or not. Thanking you Varun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Josh, That's great, thanks. When using UHD in GNU Radio, I observed huge time overhead: for example, using the raw_Ethernet code and 500kb/s, tunnel.py has only about 8 ms ping RTT time between two nodes; now with UHD, I have 17ms in average. As I increase the ping payload, the overhead time (excluding the extra data communication time) increases accordingly. Since USRP2 by default sends data samples immediately and the RTT time between UHD and USRP2 is negligible, I think that the interface between UHD and GNU Radio is introducing some overhead. Do you have any thought on this? Would you tell me what threads are running in UHD when uhd_single_usrp_sink and uhd_single_usrp_source is called? It seems that at least two threads are called for each. Is it right that the maximum amount of data that each socket.send() or socket.recv() can operate is dynamically determined by noutput_items/ninput_items from the general work function in uhd_single_usrp_*? Originally I thought the num_recv_frames have control over this; but I noticed that the UDP transport document is updated: "*Note1:* num_recv_frames and num_send_frames do not affect performance." Andrew On 03/01/2011 02:45 PM, Josh Blum wrote: Thanks a lot for the explanation. To explain your observations for the curious: Prior to the fix, a recv buffer would be lost to the transport layer on each timeout (thanks to an optimization I made earlier). So, for every 100ms window (the default timeout) that did not have at least 90 packets transmitted. A receive buffer was lost. After 32 timeouts, there were no more available buffers and the flow control throttled back. -Josh answers below: When you say 90 packets, I assume that you mean UDP packets (which contain samples). Given the default MTU (1500-8-20)B and 2 samples per symbol as well as 4B per sample, for BPSK or GMSK, 90 packets of samples correspond to 90*1472/(2*4*8)=2070B of user data. If I use 1500B per user packet, that's less than 2 packets. For 700 UDP packets, that's about 10 user packets. This actually explains what I observed, after about 10 user packets, my transmission stopped. According to you, the host blocked first. However, it seemed that USRP didn't send back update packets for some reason--which is unusual. So it's likely timeout was called. To help my understanding what caused the above behavior, would you please spend little time answering the following questions? (1) Which parameter (*ups_per_fifo or **ups_per_sec*) corresponds to the above control parameter here (90 transmission packets and 700 packets update)? (2) How is the update packet generated on USRP? (3) In normal cases, when the host transmits a packet, does it specify a transmission time for USRP? If so, it must get the clock of USRP first and then leave some margin, this introduce some time overhead; if not, does the USRP send whatever it receives immediately? (4) What's the content of the short update packet? 1) ups_per_fifo 2) it counts the number of transmitted packets, and sends an update packet every nth packet (default n = 90) 3) a transmission time is optional, when not specified the send is immediate 4) the sequence of the last transmitted packet Andrew On 02/28/2011 05:58 PM, Josh Blum wrote: A brief description on the flow control implementation: The flow control is only used on the transmit size to throttle the host calls to send(). Update packets are received by the host every 90 transmitted packets. If the host does not get an update packet after about 700 packets, the calls to send will block until the an update packet arrives or timeout. This does not incur any overhead on receive. Update packets are small, have their own dedicated udp port, and arrive infrequently. The overhead on the transmit side is a check of the flow control condition per packet. Which looks like this: return seq_type(_last_seq_out -_last_seq_ack)< _max_seqs_out; -josh On 02/28/2011 02:42 PM, Feng Andrew Ge wrote: Marc, Unfortunately I don't much experience with Ethernet pause-frame flow control. For my applications, sending is not an issue since we don't send high data rates; we are more concerned at the receiver side, particularly its latency (which is related to CPU consumption too.) Andrew On 02/28/2011 05:19 PM, Marc Epard wrote: On Feb 28, 2011, at 3:54 PM, Feng Andrew Ge wrote: Josh, I haven't found time to try what you suggested yet; however, it would be nice that the user has the option to choose host-side flow control. In principle, I don't fully trust host-side flow control simply because there is too much uncertainty in a general-purpose processor (determined by both its hardware architecture and OS). Andrew (We should probably move this to one of the public lists.) Andrew, How much experience do you have with Ethernet pause-frame flow control? It caused us a bunch of problems and judging by the lists over the last 8 months or so, it creates huge customer su
Re: [Discuss-gnuradio] GRC + N210 + RFX2200 + UHD not working
Hmm, when running git branch --track gr_uhd_next jblum/gr_uhd_next I get the error fatal: Not a valid object name: 'jblum/gr_uhd_next'. Has something changed within the past few days? -Phelps On Thu, Feb 24, 2011 at 10:15 PM, Josh Blum wrote: > > > On 02/24/2011 09:43 PM, Phelps Williams wrote: > > I'm using grc to generate some extremely simple flowgraphs but I'm seeing > > very odd performance. Any idea why I can't seem to get this combination > to > > work? I have had success with a GRC + USRP2 + WBX + UHD, anybody know > why > > I'm having issues here? > > > > Are you saying that if you run the same flow graph, host pc, ethernet > port, and software install on the USRP2 + WBX, you do not see this problem? > > I am confused about the one hardware not working while the other does, > because its functionally identical. Just wondering if we can isolate > this problem to a particular machine, software install, etc... instead. > > > UHD source block got error code 0x1 > > gr_block_executor: source produced > no > > output. We're marking it DONE. > > > > This is the call to recv() on the udp socket timing out. Either data > isnt coming over the ethernet cable for some reason recv()/select() > error-ed. > > In any case, do you mind trying the next branch? > > In the uhd repo: > git remote update > git branch --track next origin/next > git checkout next > cd host/build && make install.. > > and for gnuradio > git remote add jblum git://gnuradio.org/jblum.git > git remote update > git branch --track gr_uhd_next jblum/gr_uhd_next > git checkout gr_uhd_next > make install... > > -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] GRC + N210 + RFX2200 + UHD not working
On 03/01/2011 12:50 PM, Phelps Williams wrote: > Hmm, when running git branch --track gr_uhd_next jblum/gr_uhd_next > > I get the error fatal: Not a valid object name: 'jblum/gr_uhd_next'. > > Has something changed within the past few days? > It has been merged into gnuradio.git/next branch. Thanks, -josh > -Phelps > > On Thu, Feb 24, 2011 at 10:15 PM, Josh Blum wrote: > >> >> >> On 02/24/2011 09:43 PM, Phelps Williams wrote: >>> I'm using grc to generate some extremely simple flowgraphs but I'm seeing >>> very odd performance. Any idea why I can't seem to get this combination >> to >>> work? I have had success with a GRC + USRP2 + WBX + UHD, anybody know >> why >>> I'm having issues here? >>> >> >> Are you saying that if you run the same flow graph, host pc, ethernet >> port, and software install on the USRP2 + WBX, you do not see this problem? >> >> I am confused about the one hardware not working while the other does, >> because its functionally identical. Just wondering if we can isolate >> this problem to a particular machine, software install, etc... instead. >> >>> UHD source block got error code 0x1 >>> gr_block_executor: source produced >> no >>> output. We're marking it DONE. >>> >> >> This is the call to recv() on the udp socket timing out. Either data >> isnt coming over the ethernet cable for some reason recv()/select() >> error-ed. >> >> In any case, do you mind trying the next branch? >> >> In the uhd repo: >> git remote update >> git branch --track next origin/next >> git checkout next >> cd host/build && make install.. >> >> and for gnuradio >> git remote add jblum git://gnuradio.org/jblum.git >> git remote update >> git branch --track gr_uhd_next jblum/gr_uhd_next >> git checkout gr_uhd_next >> make install... >> >> -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] Re: UHD Announcement - February 25rd 2011
On 03/01/2011 12:52 PM, Feng Andrew Ge wrote: > Josh, > > That's great, thanks. > > When using UHD in GNU Radio, I observed huge time overhead: for example, > using the raw_Ethernet code and 500kb/s, tunnel.py has only about 8 ms > ping RTT time between two nodes; now with UHD, I have 17ms in average. > As I increase the ping payload, the overhead time (excluding the extra > data communication time) increases accordingly. Since USRP2 by default > sends data samples immediately and the RTT time between UHD and USRP2 is > negligible, I think that the interface between UHD and GNU Radio is > introducing some overhead. Do you have any thought on this? > The ping time is talking to the embedded cpu and is not a reflection of the latency when dealing with data/samples. For a better explanation, see: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000521.html Also, make sure you pull the latest gnuradio next branch. I pushed that diff I sent you earlier in regards to the time stamps. With the latest change, all packets are sent ASAP in the single channel case. > Would you tell me what threads are running in UHD when > uhd_single_usrp_sink and uhd_single_usrp_source is called? It seems that > at least two threads are called for each. > In reference to what runs on the latest master in uhd: For a USB device (USRP1) there is a thread running libusb async transactions. For a network device (USRP2/N210) there is a thread receiving async message packets, these include flow control updates and transmit error notifications. The other threads you see (and the ones with any major overhead) are the threads in gnuradio (thread-per-block scheduler) > Is it right that the maximum amount of data that each socket.send() or > socket.recv() can operate is dynamically determined by > noutput_items/ninput_items from the general work function in correct > uhd_single_usrp_*? Originally I thought the num_recv_frames have > control over this; but I noticed that the UDP transport document is > updated: "*Note1:* num_recv_frames and num_send_frames do not affect > performance." > Those refer to number of buffers allocated. But in the UDP implementation, buffers are used and disposed of synchronously, so you only ever need a few. In the libusb implementation, buffers are processed asynchronously, so you can potentially have all the buffers being emptied/filled in the background, so altering those values may make sense to do. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Josh, First of all, I am aware of what you pointed out and I did use the code latency_test.cpp for measuring latency between USRP2 and a host. The latency is negligible. I think I was not clear enough in my previous email. My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The latency I measured is based on GNU Radio-created wireless network interface, e.g., gr0. I started tunnel.py and created a digital link between host_1 and host_2; then I compared ping RTT time performance between using the UHD code and using the Raw_Ethernet code base. UHD introduced 9 ms of overhead and I am really puzzled about this. Since USRP2 sends samples immediately out and the latency between the host and USRP2 is negligible, the likely place I can think of is the interface between UHD and GNU Radio, for example, can UDP packet sending be preempted by other threads? Each time how many UDP packets can be possibly sent out? Another possibility is how you allocate CPU resources in handling UHD and what the impact might be. The third possibility is buffer management: how do you handle buffer management in UHD for sending and receiving? How do data stay in those buffers and how are data are processed, by FIFO or LIFO? If overflow happens, will newly coming packets get simply dropped? Andrew On 03/01/2011 04:18 PM, Josh Blum wrote: On 03/01/2011 12:52 PM, Feng Andrew Ge wrote: > Josh, > > That's great, thanks. > > When using UHD in GNU Radio, I observed huge time overhead: for example, > using the raw_Ethernet code and 500kb/s, tunnel.py has only about 8 ms > ping RTT time between two nodes; now with UHD, I have 17ms in average. > As I increase the ping payload, the overhead time (excluding the extra > data communication time) increases accordingly. Since USRP2 by default > sends data samples immediately and the RTT time between UHD and USRP2 is > negligible, I think that the interface between UHD and GNU Radio is > introducing some overhead. Do you have any thought on this? > The ping time is talking to the embedded cpu and is not a reflection of the latency when dealing with data/samples. For a better explanation, see: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-January/000521.html Also, make sure you pull the latest gnuradio next branch. I pushed that diff I sent you earlier in regards to the time stamps. With the latest change, all packets are sent ASAP in the single channel case. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org down? - everybody panic
___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org down?
Looks like the gnuradio.org server (web/git) is down. 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] Re: UHD Announcement - February 25rd 2011
On 03/01/2011 02:21 PM, Feng Andrew Ge wrote: > Josh, > > First of all, I am aware of what you pointed out and I did use the code > latency_test.cpp for measuring latency between USRP2 and a host. The > latency is negligible. > Ok, i see. You were measuring the ping time over the tunnel. :-) Can you tell me: Is this a new problem with UHD since the " February 25rd 2011" announcement. That is, was it working properly for you previously? > I think I was not clear enough in my previous email. > My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The > latency I measured is based on GNU Radio-created wireless network > interface, e.g., gr0. I started tunnel.py and created a digital link > between host_1 and host_2; then I compared ping RTT time performance > between using the UHD code and using the Raw_Ethernet code base. UHD > introduced 9 ms of overhead and I am really puzzled about this. Since I am puzzled as well. 9ms sounds pretty bad. Is this a port of tunnel.py to UHD, can you share it? > USRP2 sends samples immediately out and the latency between the host and > USRP2 is negligible, the likely place I can think of is the interface > between UHD and GNU Radio, for example, can UDP packet sending be > preempted by other threads? Each time how many UDP packets can be > possibly sent out? > The work function is called with a randomly sized buffer determined by the scheduler. The number of packets received or sent depends on the size of the buffer when the work() function is called. I think this is exactly the same for the raw_ethernet driver. It may be helpful to print the number of items in the work function. It seems to be in the 10s of thousands of samples last I looked. When you compared UHD vs raw_ethernet driver, it was all the same version of gnuradio, correct? > Another possibility is how you allocate CPU resources in handling UHD > and what the impact might be. > > The third possibility is buffer management: how do you handle buffer > management in UHD for sending and receiving? How do data stay in those > buffers and how are data are processed, by FIFO or LIFO? If overflow > happens, will newly coming packets get simply dropped? > Nothing gets buffered in the UHD in the usrp2/n210 implementation. However, there is a kernel socket buffer on receive that has enough buffering for a second of samples. Once this buffer fills, newer packets are dropped. I also believe that this is the same on the raw ethernet driver. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio.org down? - everybody panic
Yes, It has been down for at least a few hours... On 3/1/2011 5:59 PM, Josh Blum wrote: ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- ~Jeffrey Lambert, K1VZX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
On 03/01/2011 03:25 PM, Feng Andrew Ge wrote: > Josh, > > Everything is in the attachment, look for python-based UHD_* code. > > The performance before and after Feb.25 was both poor. At one point > before Feb. 25, the latency was even worse, up to >30ms. But I forgot > the time. > > In terms of GNU Radio, for running UHD I checked out next from GNU Radio > git. However, for raw Ethernet, I only ran GNU Radio 3.3.0. I haven't > found time to check GNU Radio changes yet, what might cause such huge > performance drop. > Andrew, Here is an idea that may explain your problem: When the raw ethernet source calls into work(), it does not attempt to fill the entire buffer (noutput_items). Rather, it waits at least one packet to become available and then copies only the data that is available immediately into the buffer. In contrast, the UHD work function is bandwidth optimized and tries to fill the entire buffer. At your sample rate (500ksps), this will impose serious delays for very large noutput_items (10s of thousands). I hope that explains the issue you see. I am going to attempt a modification to the work function, where we recv a single packet with timeout, and then anything else that is available without waiting. I will let you know when I post a branch with changes. -Josh > > Andrew > > On 03/01/2011 06:13 PM, Josh Blum wrote: >> >> On 03/01/2011 02:21 PM, Feng Andrew Ge wrote: >>> Josh, >>> >>> First of all, I am aware of what you pointed out and I did use the code >>> latency_test.cpp for measuring latency between USRP2 and a host. The >>> latency is negligible. >>> >> Ok, i see. You were measuring the ping time over the tunnel. :-) >> >> Can you tell me: Is this a new problem with UHD since the " February >> 25rd 2011" announcement. That is, was it working properly for you >> previously? >> >>> I think I was not clear enough in my previous email. >>> My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The >>> latency I measured is based on GNU Radio-created wireless network >>> interface, e.g., gr0. I started tunnel.py and created a digital link >>> between host_1 and host_2; then I compared ping RTT time performance >>> between using the UHD code and using the Raw_Ethernet code base. UHD >>> introduced 9 ms of overhead and I am really puzzled about this. Since >> I am puzzled as well. 9ms sounds pretty bad. Is this a port of tunnel.py >> to UHD, can you share it? >> >>> USRP2 sends samples immediately out and the latency between the host and >>> USRP2 is negligible, the likely place I can think of is the interface >>> between UHD and GNU Radio, for example, can UDP packet sending be >>> preempted by other threads? Each time how many UDP packets can be >>> possibly sent out? >>> >> The work function is called with a randomly sized buffer determined by >> the scheduler. The number of packets received or sent depends on the >> size of the buffer when the work() function is called. >> >> I think this is exactly the same for the raw_ethernet driver. >> >> It may be helpful to print the number of items in the work function. It >> seems to be in the 10s of thousands of samples last I looked. >> >> When you compared UHD vs raw_ethernet driver, it was all the same >> version of gnuradio, correct? >> >>> Another possibility is how you allocate CPU resources in handling UHD >>> and what the impact might be. >>> >>> The third possibility is buffer management: how do you handle buffer >>> management in UHD for sending and receiving? How do data stay in those >>> buffers and how are data are processed, by FIFO or LIFO? If overflow >>> happens, will newly coming packets get simply dropped? >>> >> Nothing gets buffered in the UHD in the usrp2/n210 implementation. >> However, there is a kernel socket buffer on receive that has enough >> buffering for a second of samples. Once this buffer fills, newer packets >> are dropped. >> >> I also believe that this is the same on the raw ethernet driver. >> >> -josh > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio.org down? - everybody panic
It's back up now. These things always happen when one's away... Tom On Tue, Mar 1, 2011 at 6:17 PM, Jeffrey Lambert wrote: > Yes, It has been down for at least a few hours... > > > On 3/1/2011 5:59 PM, Josh Blum wrote: > >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > -- > ~Jeffrey Lambert, K1VZX > > > > ___ > 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] WBX - only real signal after some time
It's working wonderfully now after I moved it to side B. More investigation is needed to find the problem... But for the moment I'll just enjoy the working set-up! (btw: the loss of the complex signal is apparently not the only problem when it's in slot A. It is also unstable and hangs after a while.. However, when it's in slot B, everything's fine) Ruben 2011/1/20 Ruben Undheim > Thanks > > I am using the traditional driver. Maybe I can try to use another computer > or to put the board in the other slot, > and see if the problem remains the same. > > Ruben > > 2011/1/20 Marcus D. Leech > > On 01/20/2011 11:40 AM, Ruben Undheim wrote: >> > Hello. >> > >> > I just wondered if anyone else has experienced that the WBX stops >> > sending the quadrature component of the complex signal after a while. >> > This happens especially if I have sliders for setting the frequencies >> > or the gain, and the sliders are slided. (so that a frequency change >> > control signal is sent several times successively) >> > In an FFT-sink, this is observed as a display mirrored around the base >> > frequency. >> > >> > I have not found any other solution to fix this than to restart the >> > whole program every time it happens. This has never happened when >> > using the TVRX board. >> The TVRX isn't actually a quadrature front-end, so quadrature is >> synthesized within the FPGA. >> >> > >> > I wonder if this is normal for these daughterboards, and that one just >> > has to ensure that they do not get a lot of frequency setting control >> > messages successively, or if there is a workaround. >> > >> I don't think it's normal. Something definitely wonky. Are you using >> UHD, or "traditional" ?? >> >> There was something *similar* in UHD a couple of months back, but it was >> for USRP2, so I don't >> think that's it. >> >> >> -- >> 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Josh, Your explanation makes sense. Is there a quick fix for me to bypass this problem temporarily while you are working on the modification. Further, following your current bandwidth optimization implementation, is the code trying to fill the buffer in both uhd_single_usrp_sink (sending buffer) and uhd_single_usrp_source (receiving buffer)? When I started uhd_benchmark_tx.py, it also asked for specification of *recv_buff_size, where is it used? * On 03/01/2011 07:01 PM, Josh Blum wrote: On 03/01/2011 03:25 PM, Feng Andrew Ge wrote: Josh, Everything is in the attachment, look for python-based UHD_* code. The performance before and after Feb.25 was both poor. At one point before Feb. 25, the latency was even worse, up to>30ms. But I forgot the time. In terms of GNU Radio, for running UHD I checked out next from GNU Radio git. However, for raw Ethernet, I only ran GNU Radio 3.3.0. I haven't found time to check GNU Radio changes yet, what might cause such huge performance drop. Andrew, Here is an idea that may explain your problem: When the raw ethernet source calls into work(), it does not attempt to fill the entire buffer (noutput_items). Rather, it waits at least one packet to become available and then copies only the data that is available immediately into the buffer. In contrast, the UHD work function is bandwidth optimized and tries to fill the entire buffer. At your sample rate (500ksps), this will impose serious delays for very large noutput_items (10s of thousands). I hope that explains the issue you see. I am going to attempt a modification to the work function, where we recv a single packet with timeout, and then anything else that is available without waiting. I will let you know when I post a branch with changes. -Josh Andrew On 03/01/2011 06:13 PM, Josh Blum wrote: On 03/01/2011 02:21 PM, Feng Andrew Ge wrote: Josh, First of all, I am aware of what you pointed out and I did use the code latency_test.cpp for measuring latency between USRP2 and a host. The latency is negligible. Ok, i see. You were measuring the ping time over the tunnel. :-) Can you tell me: Is this a new problem with UHD since the " February 25rd 2011" announcement. That is, was it working properly for you previously? I think I was not clear enough in my previous email. My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The latency I measured is based on GNU Radio-created wireless network interface, e.g., gr0. I started tunnel.py and created a digital link between host_1 and host_2; then I compared ping RTT time performance between using the UHD code and using the Raw_Ethernet code base. UHD introduced 9 ms of overhead and I am really puzzled about this. Since I am puzzled as well. 9ms sounds pretty bad. Is this a port of tunnel.py to UHD, can you share it? USRP2 sends samples immediately out and the latency between the host and USRP2 is negligible, the likely place I can think of is the interface between UHD and GNU Radio, for example, can UDP packet sending be preempted by other threads? Each time how many UDP packets can be possibly sent out? The work function is called with a randomly sized buffer determined by the scheduler. The number of packets received or sent depends on the size of the buffer when the work() function is called. I think this is exactly the same for the raw_ethernet driver. It may be helpful to print the number of items in the work function. It seems to be in the 10s of thousands of samples last I looked. When you compared UHD vs raw_ethernet driver, it was all the same version of gnuradio, correct? Another possibility is how you allocate CPU resources in handling UHD and what the impact might be. The third possibility is buffer management: how do you handle buffer management in UHD for sending and receiving? How do data stay in those buffers and how are data are processed, by FIFO or LIFO? If overflow happens, will newly coming packets get simply dropped? Nothing gets buffered in the UHD in the usrp2/n210 implementation. However, there is a kernel socket buffer on receive that has enough buffering for a second of samples. Once this buffer fills, newer packets are dropped. I also believe that this is the same on the raw ethernet driver. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC + N210 + RFX2200 + UHD not working
I think I have isolated the issue to uhd. I used the following procedure
and the benchmark_rx_rate test program appears to show the issue I've been
experiencing. I have performed the same test with a USRP2 and a WBX
daughterboard and no errors occurred.
git clone git://code.ettus.com/ettus/uhd.git
cd {UHD_ROOT}
git remote update
git branch --track next origin/next
git checkout next
cd {UHD_ROOT}/host
mkdir build
cd build
cmake ../
make
make test
sudo make install
sudo ldconfig
cd /usr/local/share/uhd/examples
./benchmark_rx_rate
linux; GNU C++ version 4.4.1; Boost_103800; UHD_003.20110226000831.77641c6
Creating the usrp device with: ...
Current recv sock buff size: 5000 bytes
mboard0 MIMO master
Using Device: Single USRP:
Device: USRP2/N Series device
Mboard 0: USRP-N210 mboard
RX DSP 0: USRP-N210 ddc0
RX Channel: 0
RX Dboard: USRP-N210 dboard (rx unit)
RX Subdev: RFX2200 (0x002c)
TX DSP 0: USRP-N210 duc0
TX Channel: 0
TX Dboard: USRP-N210 dboard (tx unit)
TX Subdev: RFX2200 (0x002d)
Testing receive rate 0.50 Msps (10.00 second run)
Error code: 1
Unexpected error on recv, exit test...
Testing receive rate 1.00 Msps (10.00 second run)
Error code: 1
Unexpected error on recv, exit test...
Testing receive rate 2.00 Msps (10.00 second run)
Error code: 1
Unexpected error on recv, exit test...
Testing receive rate 4.00 Msps (10.00 second run)
Error code: 1
Unexpected error on recv, exit test...
Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 8.00 MSps
Actual sample rate: 8.33 MSps
Testing receive rate 8.33 Msps (10.00 second run)
Error code: 1
Unexpected error on recv, exit test...
Testing receive rate 16.67 Msps (10.00 second run)
Error code: 1
Unexpected error on recv, exit test...
Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 33.33 MSps
Actual sample rate: 25.00 MSps
Testing receive rate 25.00 Msps (10.00 second run)
Error code: 1
Unexpected error on recv, exit test...
Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 50.00 MSps
Actual sample rate: 25.00 MSps
Done!
On Tue, Mar 1, 2011 at 1:07 PM, Josh Blum wrote:
>
>
> On 03/01/2011 12:50 PM, Phelps Williams wrote:
> > Hmm, when running git branch --track gr_uhd_next jblum/gr_uhd_next
> >
> > I get the error fatal: Not a valid object name: 'jblum/gr_uhd_next'.
> >
> > Has something changed within the past few days?
> >
>
> It has been merged into gnuradio.git/next branch.
>
> Thanks,
> -josh
>
> > -Phelps
> >
> > On Thu, Feb 24, 2011 at 10:15 PM, Josh Blum wrote:
> >
> >>
> >>
> >> On 02/24/2011 09:43 PM, Phelps Williams wrote:
> >>> I'm using grc to generate some extremely simple flowgraphs but I'm
> seeing
> >>> very odd performance. Any idea why I can't seem to get this
> combination
> >> to
> >>> work? I have had success with a GRC + USRP2 + WBX + UHD, anybody know
> >> why
> >>> I'm having issues here?
> >>>
> >>
> >> Are you saying that if you run the same flow graph, host pc, ethernet
> >> port, and software install on the USRP2 + WBX, you do not see this
> problem?
> >>
> >> I am confused about the one hardware not working while the other does,
> >> because its functionally identical. Just wondering if we can isolate
> >> this problem to a particular machine, software install, etc... instead.
> >>
> >>> UHD source block got error code 0x1
> >>> gr_block_executor: source
> produced
> >> no
> >>> output. We're marking it DONE.
> >>>
> >>
> >> This is the call to recv() on the udp socket timing out. Either data
> >> isnt coming over the ethernet cable for some reason recv()/select()
> >> error-ed.
> >>
> >> In any case, do you mind trying the next branch?
> >>
> >> In the uhd repo:
> >> git remote update
> >> git branch --track next origin/next
> >> git checkout next
> >> cd host/build && make install..
> >>
> >> and for gnuradio
> >> git remote add jblum git://gnuradio.org/jblum.git
> >> git remote update
> >> git branch --track gr_uhd_next jblum/gr_uhd_next
> >> git checkout gr_uhd_next
> >> make install...
> >>
> >> -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] Re: UHD Announcement - February 25rd 2011
On 03/01/2011 04:39 PM, Feng Andrew Ge wrote: > Josh, > > Your explanation makes sense. Is there a quick fix for me to bypass > this problem temporarily while you are working on the modification. > http://gnuradio.org/cgit/jblum.git/commit/?id=75538e12300cb0d593792a986841ba2df9997c54 :-) > Further, following your current bandwidth optimization implementation, > is the code trying to fill the buffer in both uhd_single_usrp_sink > (sending buffer) and uhd_single_usrp_source (receiving buffer)? > For the source, the work function waits for the entire RX buffer to be filled with samples. I strongly believe this is the cause of the latency. For the sink, the work function sends the entire buffer. This is correct behavior for optimum latency and bandwidth. > When I started uhd_benchmark_tx.py, it also asked for specification of > *recv_buff_size, where is it used? * > http://www.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers -Josh > > On 03/01/2011 07:01 PM, Josh Blum wrote: >> >> On 03/01/2011 03:25 PM, Feng Andrew Ge wrote: >>> Josh, >>> >>> Everything is in the attachment, look for python-based UHD_* code. >>> >>> The performance before and after Feb.25 was both poor. At one point >>> before Feb. 25, the latency was even worse, up to>30ms. But I forgot >>> the time. >>> >>> In terms of GNU Radio, for running UHD I checked out next from GNU Radio >>> git. However, for raw Ethernet, I only ran GNU Radio 3.3.0. I haven't >>> found time to check GNU Radio changes yet, what might cause such huge >>> performance drop. >>> >> Andrew, >> >> Here is an idea that may explain your problem: >> >> When the raw ethernet source calls into work(), it does not attempt to >> fill the entire buffer (noutput_items). Rather, it waits at least one >> packet to become available and then copies only the data that is >> available immediately into the buffer. >> >> In contrast, the UHD work function is bandwidth optimized and tries to >> fill the entire buffer. At your sample rate (500ksps), this will impose >> serious delays for very large noutput_items (10s of thousands). I hope >> that explains the issue you see. >> >> I am going to attempt a modification to the work function, where we recv >> a single packet with timeout, and then anything else that is available >> without waiting. >> >> I will let you know when I post a branch with changes. >> -Josh >> >>> Andrew >>> >>> On 03/01/2011 06:13 PM, Josh Blum wrote: On 03/01/2011 02:21 PM, Feng Andrew Ge wrote: > Josh, > > First of all, I am aware of what you pointed out and I did use the > code > latency_test.cpp for measuring latency between USRP2 and a host. The > latency is negligible. > Ok, i see. You were measuring the ping time over the tunnel. :-) Can you tell me: Is this a new problem with UHD since the " February 25rd 2011" announcement. That is, was it working properly for you previously? > I think I was not clear enough in my previous email. > My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The > latency I measured is based on GNU Radio-created wireless network > interface, e.g., gr0. I started tunnel.py and created a digital link > between host_1 and host_2; then I compared ping RTT time performance > between using the UHD code and using the Raw_Ethernet code base. UHD > introduced 9 ms of overhead and I am really puzzled about this. Since I am puzzled as well. 9ms sounds pretty bad. Is this a port of tunnel.py to UHD, can you share it? > USRP2 sends samples immediately out and the latency between the > host and > USRP2 is negligible, the likely place I can think of is the interface > between UHD and GNU Radio, for example, can UDP packet sending be > preempted by other threads? Each time how many UDP packets can be > possibly sent out? > The work function is called with a randomly sized buffer determined by the scheduler. The number of packets received or sent depends on the size of the buffer when the work() function is called. I think this is exactly the same for the raw_ethernet driver. It may be helpful to print the number of items in the work function. It seems to be in the 10s of thousands of samples last I looked. When you compared UHD vs raw_ethernet driver, it was all the same version of gnuradio, correct? > Another possibility is how you allocate CPU resources in handling UHD > and what the impact might be. > > The third possibility is buffer management: how do you handle buffer > management in UHD for sending and receiving? How do data stay in those > buffers and how are data are processed, by FIFO or LIFO? If overflow > happens, will newly coming packets get simply dropped? > Nothing gets buffered in the UHD in the usrp2/n210 implementation. However, there is a k
[Discuss-gnuradio] Zynq-7000
Just saw that Xilinx has announced the Zynq-7000 family -- chips that combine a dual-core ARM Cortex-A9 processor and peripherals with programmable logic cells (i.e., FPGA fabric). Seems like this could make a pretty good base for an embedded gnuradio platform. Anyone looked at this yet? Details at http://www.xilinx.com/publications/prod_mktg/zynq7000/Product-Brief.pdf /jordan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] new feature work: qtgui support in grc
Hey list, I have been working on supporting PyQt widgets and the qtgui sinks in the Gnuradio Companion. Get the code on my wip/qtgui/grc branch on jblum.git http://gnuradio.org/cgit/jblum.git/log/?h=wip/qtgui/grc Available widgets: * qtgui plotter (dft, scope, etc) * tabbed panel * slider * combo box * radio buttons * text entry * label 1) The slider adds a new requirement of PyQwt (python Qwt bindings). Qwt should already be installed for the qtgui sinks themselves. 2) The qtgui and wxgui widgets are distinctly separated. Previously, the "variable slider" was a wx slider form. Now, there is a WX GUI Slider and a QT GUI Slider. And the generate options now have a QT GUI option. You cannot mix and match widgets from different graphics libraries. 3) No attempt was made to make the existence of different graphics toolkits transparent to the user. That would have been a huge pain on my part and I couldn't try new things. If this Qt thing catches on, I am considering a migration script from wx->qt. 4) The Qt widgets in grc do not have a python wrapper/forms library like they do in gnuradio. All the generated code uses the PyQt API directly. This is in-part possible because Qwt supplies its own set of useful wrappers around Qt widgets. Examples: http://qwt.sourceforge.net/sliders.png 5) Each widget block in grc has a gui hint parameter. This parameter is a combination of the grid parameter and notebook parameter seen in the wx widget blocks. It also allowed the implementation code to be a lot more generic. Whats missing? I feel that the widgets still need a bit of polishing. Engineering notation would be nice. I'd like to see features in the wx scope sink brought to the qtgui scope such as trigger modes and multiple channels. I think the qt equivalent of the numbersink would be nice too (and that could use some of those real fancy qwt widets): http://read.pudn.com/downloads186/sourcecode/embed/872381/qwt/doc/images/dials2.png Why qtgui stuff? The WX stuff in gnuradio is fairly polished in comparison; and when it works, it works. But we have seen many issues with wx outside of the linux+x86 world, not to mention opengl issues on the x86. I hope that the qt stuff is a viable, cross platform option for live gnuradio plotting and graphical applications. Please try it out. Feedback is welcome! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Zynq-7000
On 03/01/2011 08:27 PM, Jordan Hayes wrote: Just saw that Xilinx has announced the Zynq-7000 family -- chips that combine a dual-core ARM Cortex-A9 processor and peripherals with programmable logic cells (i.e., FPGA fabric). Seems like this could make a pretty good base for an embedded gnuradio platform. Anyone looked at this yet? Details at http://www.xilinx.com/publications/prod_mktg/zynq7000/Product-Brief.pdf Yes, this is an exciting product. Xilinx announced this last April during an Embedded Conference. They are slowly releasing technical details, but what I haven't seen in the announcements is a solid time frame for getting silicon and dev boards :( Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM Receiver
Hi, I agree that it is a sample rate issue. The USRP sends too many data to the computer which becomes overrun. As you said, I put a Polyphase Resampler between the USRP and the WBFM receive blocks ( http://old.nabble.com/file/p31046181/fm_receiver.py fm_receiver.py ). But, when I execute the flow graph, I get this message : PCM name: hw:0,0 Access types: MMAP_INTERLEAVED YES MMAP_NONINTERLEAVED NO MMAP_COMPLEX NO RW_INTERLEAVED YES RW_NONINTERLEAVEDNO Formats: S16_LE YES Number of channels min channels: 2 max channels: 2 2 channels YES Sample Rates: min rate:8000 (dir = 0) max rate: 48000 (dir = 0) 8000 YES 16000 YES 22050 YES 32000 YES 44100 YES 48000 YES 96000 NO 192000 NO audio_alsa_sink[hw:0,0]: using S16_LE >>> gr_fir_ccf: using SSE >>> Done Nothing happens and I can no longer see the FFT sink window. By the way, sorry for the delay of my response, but I have not worked on this project for a couple of days. Francois Tom Rondeau wrote: > > On Thu, Feb 24, 2011 at 10:28 PM, Anoth > wrote: >> >> Yes, you must be right, I must have made a mistake when I set up the flow >> graph. How do you know the sample rate delivered by the UHD and how is >> the >> Polyphase Resampler implemented into the flow graph ? >> >> Francois > > Not entirely sure how to do this in GRC... When you set the sample > rate of the UHD device, you can request back what it was actually set > to using "get_samp_rate". So if you were doing this just in Python, > you can have: > > req_sr = SR > act_sr = uhd.get_samp_rate() > resamp_rate = req_sr / act_sr > resampler = blks2.pfb_arb_resampler(resamp_rate) > > Unless, of course, it's "resamp_rate = act_sr/req_sr". I've been > working too long today to reason that out. > > I'm sure there is a way to do this in GRC by knowing the name of the > UHD device and using it; I've just never done it. > > Tom > > > >> Tom Rondeau wrote: >>> >>> On Thu, Feb 24, 2011 at 7:17 PM, Anoth >>> wrote: Hi Josh, Yes, I have already though about that and I tried to match the sample and sound card rates without success (but I might made a mistake). I have also read on the Internet that it might come from the sound card which cannot support all rates but I did not find anything more about that subject. Here the python code generated by GRC : http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py Francois >>> >>> I think Josh is right and it's a sampling rate error. When you set the >>> sampling rate of the USRP, ask the UHD driver what the current >>> sampling rate is. Use what it returns to you to adjust the sampling >>> rate properly. I ran into this same issue and solved it by using the >>> pfb_arb_resampler block (Polyphase Resampler in GRC) to adjust the >>> rates correctly. >>> >>> Tom >>> >>> Josh Blum-2 wrote: > > > gr_fir_ccc: using SSE >> aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU >> > > These characters being printed means that you have mismatched sample > rates between your USRP device and sound card. Could this be the case? > > -josh > > ___ > 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/FM-Receiver-tp31009069p31009164.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 mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/FM-Receiver-tp31009069p31010011.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 mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/FM-Receiver-tp31009069p31046181.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
Re: [Discuss-gnuradio] FM Receiver
Hi again, I resolved my problem without using the Polyphase Resampler. It was a sample rate issue which did not match the requirements of the audio card. Anyway, thank you a lot for your help. Francois Anoth wrote: > > Hi, > > I agree that it is a sample rate issue. The USRP sends too many data to > the computer which becomes overrun. As you said, I put a Polyphase > Resampler between the USRP and the WBFM receive blocks ( > http://old.nabble.com/file/p31046181/fm_receiver.py fm_receiver.py ). But, > when I execute the flow graph, I get this message : > > PCM name: hw:0,0 > Access types: > MMAP_INTERLEAVED YES > MMAP_NONINTERLEAVED NO > MMAP_COMPLEX NO > RW_INTERLEAVED YES > RW_NONINTERLEAVEDNO > Formats: > S16_LE YES > Number of channels > min channels: 2 > max channels: 2 > 2 channelsYES > Sample Rates: > min rate:8000 (dir = 0) > max rate: 48000 (dir = 0) > 8000 YES > 16000 YES > 22050 YES > 32000 YES > 44100 YES > 48000 YES > 96000 NO > 192000 NO > audio_alsa_sink[hw:0,0]: using S16_LE gr_fir_ccf: using SSE > Done > > Nothing happens and I can no longer see the FFT sink window. By the way, > sorry for the delay of my response, but I have not worked on this project > for a couple of days. > > Francois > > > Tom Rondeau wrote: >> >> On Thu, Feb 24, 2011 at 10:28 PM, Anoth >> wrote: >>> >>> Yes, you must be right, I must have made a mistake when I set up the >>> flow >>> graph. How do you know the sample rate delivered by the UHD and how is >>> the >>> Polyphase Resampler implemented into the flow graph ? >>> >>> Francois >> >> Not entirely sure how to do this in GRC... When you set the sample >> rate of the UHD device, you can request back what it was actually set >> to using "get_samp_rate". So if you were doing this just in Python, >> you can have: >> >> req_sr = SR >> act_sr = uhd.get_samp_rate() >> resamp_rate = req_sr / act_sr >> resampler = blks2.pfb_arb_resampler(resamp_rate) >> >> Unless, of course, it's "resamp_rate = act_sr/req_sr". I've been >> working too long today to reason that out. >> >> I'm sure there is a way to do this in GRC by knowing the name of the >> UHD device and using it; I've just never done it. >> >> Tom >> >> >> >>> Tom Rondeau wrote: On Thu, Feb 24, 2011 at 7:17 PM, Anoth wrote: > > Hi Josh, > > Yes, I have already though about that and I tried to match the sample > and > sound card rates without success (but I might made a mistake). I have > also > read on the Internet that it might come from the sound card which > cannot > support all rates but I did not find anything more about that subject. > Here > the python code generated by GRC : > http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py > > Francois I think Josh is right and it's a sampling rate error. When you set the sampling rate of the USRP, ask the UHD driver what the current sampling rate is. Use what it returns to you to adjust the sampling rate properly. I ran into this same issue and solved it by using the pfb_arb_resampler block (Polyphase Resampler in GRC) to adjust the rates correctly. Tom > Josh Blum-2 wrote: >> >> >> gr_fir_ccc: using SSE >>> aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU >>> >> >> These characters being printed means that you have mismatched sample >> rates between your USRP device and sound card. Could this be the >> case? >> >> -josh >> >> ___ >> 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/FM-Receiver-tp31009069p31009164.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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/FM-Receiver-tp31009069p31010011.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 mailing list >> Discuss-gnuradio@gnu
[Discuss-gnuradio] smart pointer problem
Hi, I'm fighting a bit with a smart pointer. I want to apply a filter in my block. Hence I construct a filter as shown below: gr_fir_filter_fff_sptr hi_pass = gr_make_fir_filter_fff(1, gr_firdes::high_pass (1.0, 64000, 5000, 1000, gr_firdes::WIN_HAMMING, 6.76 )); as soon as I dereference the smart pointer in order to use the filter I get an assertion error: const [with T = gr_block_detail]: Assertion `px != 0' failed. hi_pass->general_work(noutput_items, ninput_items, input_items, output_items); this means the smart pointer doesn't have a pointer (any longer?) to the filter. Does anyone see what I'm doing wrong. I've been trying quite hard to find the mistake but I simply don't get it. Cheers, John. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
