Re: [Discuss-gnuradio] Questions on DDC output
Hi, Checkout the USRP measurement pointed by : http://www.nabble.com/USRP-Dynamic-Range-and-8-Bit-Problem-to14471573.html#a14484747 May be it will answer some of your questions. Keep in your mind that USRP is not a measurement device. It is an SDR peripheral device. If you want to use it as a measurement device, you should use a calibration method to modify its output to fit into your requirements. Regards, Firas Brook Lin wrote: > > Hi All, > > I found one of replies sent by Eric said that: > >>What are the units of the Y axis of usrp_oscope? > >>They are the output of the digital down converter. >>They are not calibrated to any particular voltage level. >>The levels depend on the gain setting too. > > My first question now is whether the red and blue lines on the oscope are > the numbers which are the 12-bit output of the ADC multiply the > sine/cosine @ IF? Eric said that the levels depend on the gain setting > too. If the gain is 0, do these show the actual signal receving by the > USRP in time domain? So the Y-axis should be mV when gain is 0, right? > However, I don't think the gain and the output are linear. How does the > gain effect the output of the DDC? > > My second question is when gain is 0, usrp_fft.py shows the actual signal > in frequency domain, and Y-axis are in mdB. Am I right? What is the 0dB in > fft? Is it exact 0 or some reference number? > > Thanks, > Brook > -- View this message in context: http://www.nabble.com/Questions-on-DDC-output-tp14897066p14948024.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] Need info for paper.
John Clark wrote: George Nychis schrieb: Hi John, There are a couple other SDR-type platforms in the academic world... but none really come close to the code base of GR IMO. Some of these seemed pretty 'expensive' to get into... the use of ASICs, and the like, also, they seem to be directed to pretty specific implementations of transmissions, even though one could conceivably load in a new chunk of firmware 'on the fly' perhaps... Along those lines are Lyrtech's boards (the Small Form Factor (SFF) SDR) and TI has something similar. These are almost all FPGA-based SDR devices, and I'm not sure what kind of software you get with them to do any communications. And they are very expensive. WARP is a very expensive platform IMO, and they are not as modular as GNU Radio. I would say GNU Radio has far more in the PHY layer, and WARP has 1 PHY (OFDM) + a bunch of MAC implementations. Looked interesting, but did have this overhead of ASIC, and buying the attendant boards. The KU Agile radio is still pretty new, Prof. Minden gave a talk here about it last semester and it seemed the hardware was pretty concrete but the software was still in progress... which is what truly separates SDR platforms :) Looks closest to what I'm doing... albeit not with a PPC core... Gary's new design uses an Intel chip, though I'm not sure where they are on production. I've seen them work, though, and they provided a nice demonstration of the KUAR at the IEEE DySPAN conference in Dublin last year. I hope to get them back for this year's, too. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Measure BER
Hi all, I'm currently working on a GSMK modem, and I would like to calculate the BER of the link. I send data using gr.vector_source_b( ) connected to a GMSK modulator/demodulator and receive the signal in gr.vector_sink_b( ). 1) How can I measure BER from the vector_source and vector_sink ? 2) Does a BER calculator recovering from clock shifting (bit lost by clock sliding) exist ? Thanks ! -- View this message in context: http://www.nabble.com/Measure-BER-tp14952951p14952951.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] Need info for paper.
On Jan 17, 2008, at 8:57 PM, Martin Dvh wrote: If you need any other kind of info, please let me know. I have done some presentations on GnuRadio and Software Defined Radio and I am preparing for some GnuRadio courses that I will be giving. It would be appreciated if you made the paper public and available somewhere on the web. Martin - Are your presentations linked into the Wiki, or available elsewhere for general viewing? I, for one, would love to see them. I, too, am writing a paper that will (among other things) discuss GNU Radio and USRP and alternatives to them. I'm happy to provide a summery, on or off-list, of what I've learned / written. Assuming the paper gets published, then we'll make sure to link it in the GR wiki. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
I've seen this exact same behavior for some time. I'm currently running the latest GnuRadio release and GRC 0.69 on Mac OSX 10.4.11 @(^.^)@ Ed Achilleas Anastasopoulos wrote: I would like to thank again Josh for the wonderfull job on GRC: I am now using it regularly for my classroom demonstrations on analog/digital communications. I have noticed (it has been more than 6 months since the last time I used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). In fact, 8 out of 10 times that I stop a running graph (usually with 4-5 graphical sinks running) either by closing the graph window or by pressing the "stop" button on the graphical editor of GRC, it closes the entire GRC editor... Can someone confirm this behavior? Thanks Achilleas PS: I have to add one more item on my wish list for 0.70 :-) In the "open file" and "save file" dialog boxes, make "open" and "save" the default action when pressing "enter", so you wont have to press the button with the mouse... ___ 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] Measure BER
Hi, BER is defined as the % of bits that have errors to the total number of bits. Therefore, you need to calculate the number of incorrect bits. To do this you would need to know the correct bits to compare your received bits to. You can then easily compute the number of incorrect bits. Therefore, if the input to gr.vector_source_b() is your input data, you would compare it to the output of gr.vector_sink_b() and calculate the bit difference. If 1 bit out of 10^3 bits are different, your BER is 1/10^3. The more input, the more accurate your BER estimate is. I don't think a BER calculator exists in GR, but it shouldn't be that difficult. The block would take two input streams, one being the correct data and the other being the decoded data. It could then compare the two. Or you could compare the two outside of GNU Radio pretty easily. It's not clear to me if you're performing the modulation and demodulation on the same machine. If so you have easy access to both data sets. Otherwise, transfer the known data to the receiver in a 100% accurate method and then compare. - George irene159 wrote: Hi all, I'm currently working on a GSMK modem, and I would like to calculate the BER of the link. I send data using gr.vector_source_b( ) connected to a GMSK modulator/demodulator and receive the signal in gr.vector_sink_b( ). 1) How can I measure BER from the vector_source and vector_sink ? 2) Does a BER calculator recovering from clock shifting (bit lost by clock sliding) exist ? Thanks ! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] blks2.synthesis_filterbank
On 1/18/08, beezle bub <[EMAIL PROTECTED]> wrote: > It might be the case that if I fix my own code, I can also fix the > blks2.synthesis_filterbank. Let me know what you find. I haven't looked at your bug report yet. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
The error seems to come from gtk.main and not from the GRC source itself. Perhaps this is the result of a race condition (in grc) between the the main thread and the thread waiting on the flow graph to finish. ->By clicking the kill button, the waiting thread finishes by calling the very same method that handles the "kill button" press. Perhaps in all the ruckus, some gtk functions get called by 2 threads at once, and eventually gtk gets upset and dies/crashes... I committed a fix for this in the GRC trunk. Can somebody with this issue try out the trunk fix and let me know? -Josh Ed Criscuolo wrote: I've seen this exact same behavior for some time. I'm currently running the latest GnuRadio release and GRC 0.69 on Mac OSX 10.4.11 @(^.^)@ Ed Achilleas Anastasopoulos wrote: I would like to thank again Josh for the wonderfull job on GRC: I am now using it regularly for my classroom demonstrations on analog/digital communications. I have noticed (it has been more than 6 months since the last time I used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). In fact, 8 out of 10 times that I stop a running graph (usually with 4-5 graphical sinks running) either by closing the graph window or by pressing the "stop" button on the graphical editor of GRC, it closes the entire GRC editor... Can someone confirm this behavior? Thanks Achilleas PS: I have to add one more item on my wish list for 0.70 :-) In the "open file" and "save file" dialog boxes, make "open" and "save" the default action when pressing "enter", so you wont have to press the button with the mouse... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Information on ticket:181 and invitation to help (long)
Here's a sample with: Gnu Radio 3.1.1 g++ 4.0.1 Python 2.4.4 Swig 1.3.33 OSX 10.4.11 [eds-mac:~] edwardc% python Python 2.4.4 (#1, Dec 19 2007, 10:55:40) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_general.py", line 2837, in hilbert return _gnuradio_swig_py_general.firdes_hilbert(*args) IndexError: Hilbert: Must have odd number of taps >>> ^D [eds-mac:~] edwardc% g++ --version i686-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [eds-mac:~] edwardc% swig -version SWIG Version 1.3.31 Compiled with /usr/bin/g++-4.0 [i686-apple-darwin8.8.2] Please see http://www.swig.org for reporting bugs and further information [eds-mac:~] edwardc% uname -a Darwin eds-mac.gsfc.nasa.gov 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 @(^.^)@ Ed Johnathan Corgan wrote: So far from all the reports (thanks guys, keep them coming), the works/fails distinction is whether gcc is < 4.1 or not. But we don't have enough "works" examples to really draw that conclusion yet. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Measure BER
George Nychis wrote: Hi, BER is defined as the % of bits that have errors to the total number of bits. Therefore, you need to calculate the number of incorrect bits. To do this you would need to know the correct bits to compare your received bits to. You can then easily compute the number of incorrect bits. Therefore, if the input to gr.vector_source_b() is your input data, you would compare it to the output of gr.vector_sink_b() and calculate the bit difference. If 1 bit out of 10^3 bits are different, your BER is 1/10^3. The more input, the more accurate your BER estimate is. I don't think a BER calculator exists in GR, but it shouldn't be that difficult. The block would take two input streams, one being the correct data and the other being the decoded data. It could then compare the two. The only difficulty is the delay introduced by the flowgraph, specifically through filters. You can brute force this by looking at the output and figuring out the delay. I noticed, though, when I was working on my dissertation, certain flow graphs would have an uncertain delay, though I wasn't sure why (I think it was GMSK, too, which would have a 7 or 8 sample delay on any given run). Or you could compare the two outside of GNU Radio pretty easily. It's not clear to me if you're performing the modulation and demodulation on the same machine. If so you have easy access to both data sets. Otherwise, transfer the known data to the receiver in a 100% accurate method and then compare. Much easier on the same machine. The BER block I wrote works well in this case and automatically adjusts for the delay by looking for a start packet. It's a bit crude and awkward to use the block, which is why I haven't checked it into the project yet. The results, though, were _very_ good. Within a few tenths of a dB to theory. GMSK had a problem at SNRs lower than about 5 dB. Tom - George irene159 wrote: Hi all, I'm currently working on a GSMK modem, and I would like to calculate the BER of the link. I send data using gr.vector_source_b( ) connected to a GMSK modulator/demodulator and receive the signal in gr.vector_sink_b( ). 1) How can I measure BER from the vector_source and vector_sink ? 2) Does a BER calculator recovering from clock shifting (bit lost by clock sliding) exist ? Thanks ! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] blks2.synthesis_filterbank
So, interesting things. Incidentally, I was the guy who posted about the segfault in top_block. 1) On my laptop runing ubuntu 7.10 natively with latest stuff installed, I got the segfault. On my virtualized ubuntu on my macbook, I got a real error message (btw & fyi, ubuntu + parallels does not work with the USRP). 2) The error message that I got as that was segfaulting the native ubuntu was the same error message I was getting for the blks2.synthesis_filterbank: "insufficient connected output ports (2 needed, 1 connected)" The difference is that I'm getting the error because of my C++ block (either because of the C++ code, or how it was connected in the python). It might be the case that if I fix my own code, I can also fix the blks2.synthesis_filterbank. Cheers, -Ben > Date: Tue, 15 Jan 2008 09:42:21 -0800 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED]; Discuss-gnuradio@gnu.org; [EMAIL PROTECTED] > Subject: Re: [Discuss-gnuradio] blks2.synthesis_filterbank > > Eric Blossom wrote: >> On Mon, Jan 14, 2008 at 11:18:15PM -0800, benjar wrote: >>> Hey guys, >>> >>> I was wondering if the whole hier_block2 thing was working yet. > > To answer this particular question--yes. The new top_block/hier_block2 > code has been in the stable branch since 3.1.0, and all our examples and > QA code have been switched over to use it on our development trunk. So > it gets exercised quite frequently. > >>> Is this a bug in the filterbank code > > I suspect that when the block was switched to use the new > top_block/hier_block2 code, a bug was introduced. > > However, the gr-pager scripts use blks2.analysis_filterbank successfully. > > > From Eric: > >> Not sure what the other problem is. >> Johnathan, can you take a look at this? > > Will do. > > -- > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
G'day, Still crashes here with the following error messages: No module named serial in RS232 Source! -> continuing... No module named serial in RS232 Sink! -> continuing... Removing empty category "Custom"... >>> Verbose: Traceback (most recent call last): File "/home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py", line 248, in ? exit(0) TypeError: 'str' object is not callable >>> Done The program 'Editor.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 10975 error_code 16 request_code 151 minor_code 23) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) cheerio Berndt On Saturday 19 January 2008 05:38:46 Josh Blum wrote: > The error seems to come from gtk.main and not from the GRC source > itself. Perhaps this is the result of a race condition (in grc) between > the the main thread and the thread waiting on the flow graph to finish. > > ->By clicking the kill button, the waiting thread finishes by calling > the very same method that handles the "kill button" press. Perhaps in > all the ruckus, some gtk functions get called by 2 threads at once, and > eventually gtk gets upset and dies/crashes... > > I committed a fix for this in the GRC trunk. Can somebody with this > issue try out the trunk fix and let me know? > > -Josh > > Ed Criscuolo wrote: > > I've seen this exact same behavior for some time. I'm currently > > running the latest GnuRadio release and GRC 0.69 on Mac OSX 10.4.11 > > > > @(^.^)@ Ed > > > > Achilleas Anastasopoulos wrote: > >> I would like to thank again Josh for the wonderfull job on GRC: > >> I am now using it regularly for my classroom demonstrations on > >> analog/digital communications. > >> > >> I have noticed (it has been more than 6 months since the last time I > >> used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). > >> In fact, 8 out of 10 times that I stop a running graph (usually with > >> 4-5 graphical sinks running) either by closing the graph window or by > >> pressing the "stop" button on the graphical editor of GRC, it closes > >> the entire GRC editor... > >> > >> Can someone confirm this behavior? > >> > >> Thanks > >> Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need info for paper.
I have two of the Lyrtech boards and with the develpment tools for DSP chip and FPGA. Using Matlab simulink, and code generation, etc. for rapid prototyping this is just about ohh, one hundred grand.. The Matlab is shared license at work as is the DSP and FPGA development tools but this is well out of reach of most. Bob Tom Rondeau wrote: John Clark wrote: George Nychis schrieb: Hi John, There are a couple other SDR-type platforms in the academic world... but none really come close to the code base of GR IMO. Some of these seemed pretty 'expensive' to get into... the use of ASICs, and the like, also, they seem to be directed to pretty specific implementations of transmissions, even though one could conceivably load in a new chunk of firmware 'on the fly' perhaps... Along those lines are Lyrtech's boards (the Small Form Factor (SFF) SDR) and TI has something similar. These are almost all FPGA-based SDR devices, and I'm not sure what kind of software you get with them to do any communications. And they are very expensive. --- snip Gary's new design uses an Intel chip, though I'm not sure where they are on production. I've seen them work, though, and they provided a nice demonstration of the KUAR at the IEEE DySPAN conference in Dublin last year. I hope to get them back for this year's, too. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
