Re: [Discuss-gnuradio] Shared Sources
Tom Rondeau wrote on 2012-06-05 02:47: > On Mon, Jun 4, 2012 at 3:08 PM, Martin Braun wrote: >> On Mon, Jun 04, 2012 at 12:37:31PM -0400, Andrew Davis wrote: >>> I would recommend file sources, you can filter, graph and demod them >>> w/o hardware. >> >> Check out http://gnuradio.org/redmine/projects/gnuradio/wiki/SampleData >> for prerecorded stuff. It's not much, though. >> >> MB > > There are also some files here: > http://gnuradio.org/data/ > > I think we should start a real collection of some useful data files > for different projects. We can't go crazy with this, but there's > plenty of space on our web server for a good collection. I think it would be helpfull to have good metadata with the recordings, maybe some naming scheme, which gives consistant information about the recording, allong with some info text, that describes the setting of the recording and the identified signals. Moreover I think there should be bigger and smaller files. Not everyone needs 8MHz recordings which yield gigibytes of data within seconds, not everyone has the space and connection bandwidth to store them or the computing power to process them. Small is beautiful, narrow band and short recordings can fulfill most demands. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
Tom Rondeau wrote on 2012-06-06 01:12: > On Tue, Jun 5, 2012 at 10:06 AM, Patrick Strasser > wrote: >> Tom Rondeau wrote on 2012-06-04 14:18: >>> On Sun, Jun 3, 2012 at 2:22 PM, Patrick Strasser >>> wrote: >>>> Full valgrind log in >>>> http://pastebin.com/7GCs3bWy >> What seems strange to me is the allocation of a buffer of a non by 8 >> dividable size, that is accessed in blocks of 8 bytes. So the last read >> always either does not touch the end of the buffer, or it reads beyond >> the end. > > Sorry, Patrick, I think there was a typo or something in your first > sentence, and I'm not sure I understood. But from the gist of it, yes, > if the items used in a block have size 8, then the buffer allocation > should be sized enough to handle an integer number of items. This is > true because the scheduler sends the block noutput_items, which are > the number of items to process (so the buffer size would be > 8*noutput_items). To make it more clear: >From the valgrind log: ==19688== Invalid read of size 8 [...] ==19688== Address 0x1a200600 is 1 bytes after a block of size 447 alloc'd [...] ==19688==by 0x4F7AF67: gr_fir_fff_simd::set_taps(std::vector > const&) (gr_fir_fff_simd.cc:88) [...] ==19688==by 0x4F8DF06: gr_make_rational_resampler_base_fff(unsigned int, unsigned int, std::vector > const&) (gr_rational_resampler_base_fff.cc:45) I do not completely understand where this number is calculated, but a buffer of size 447 is allocated, and later accessed in steps of 8. Btw even if the buffer was a multiple of 8, the read would be out of bounds. Anyway, reading out of bounds may trigger a segfault if you are lucky, if you are not, it goes unnoticed and you get wrong/weird results. I wonder if this stems from an error in the application. Is it possible to mis-use the API to trigger something like this that would not happen if everything was used rigth? I'm sorry if my mails are not always completely clear and understandable, still trying to improve my English on technical topics that are new to me ;-) Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gqrx branch osmosdr
Alexandru Csete wrote on 2012-06-05 19:06: > There is no audio filter yet (except de-emphasis) so you get pretty > much 48 kHz worth of noise, including stereo pilot tone and whatever > crap they include in a broadcast FM channel these days. I put in some debugging code near the filter tap calculations to see the resulting filters. Would be nice to display the real filter curve in the spectrum, with some infos like the cutoff frequencies, transistion width and number of taps (complexity), maybe next week I can play on that. Printing out the taps, pasting into an octave instance, fft and plotting was straigth forward. I love it when a plan comes together! Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gqrx branch osmosdr
Alexandru Csete wrote on 2012-06-05 19:06: > On Tue, Jun 5, 2012 at 6:51 PM, Patrick Strasser >> In comparison to the rtlsdr fork I see you added FM-W. FM-N in >> comparison sounds more clipped, FM-W is clipped with a narrow filter, >> but noisy with a wide filter. With a filter that has no clipping, noise >> is clearly audible. I'm not sure if this is bound by the low dynamic >> sampling range (8 bit) in combination with big bandwith which means a >> lot more noise energy with wide filters. Anyway, gqrx gets greater every >> time! > > There is no audio filter yet (except de-emphasis) so you get pretty > much 48 kHz worth of noise, including stereo pilot tone and whatever > crap they include in a broadcast FM channel these days. It's AM and some special BPSK. Nice ensemble of different analogue and digital schemes, maybe we'll use it as an demonstration in one of our lectures here at University. Anyway, my ears have a builtin filter that cuts dramatically everything above some 18kHz, not sure if I can hear the pilot tone. If you are not doing dirty tricks every decimating filter should prevent aliasing, so no effect of everything that's higher than half the sampling rate. With 48 kHz you should not get even close to the higher energy parts of AM at arround 38kHz. I guess where noise comes in is before FM demodulation: the bigger the sampled frequency bandwidth, the more noise energy. With the limited dynamic range this decreases the signal (FM) to noise (background) ratio, which opposes good demodulation results. Per design and regulation a FM radio signal has mono 180 kHz bandwidth and stere 300 kHz, but I do not know of a station sending in mono here in Austria. Maybe a kind of matched filter would be best: you can expect that the wider fare a frequency is from center frequency, the less energy it has. Maybe thirds would work: < -150 kHz stop, up to -50 kHz transition, -50 to +50 kHz pass, +50 up to +150 transition, and then again stop. Frequency deviation is specified as 75 kHz. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gqrx branch osmosdr
Alexandru Csete wrote on 2012-06-05 16:36: > On Tue, Jun 5, 2012 at 4:02 PM, Patrick Strasser >> v2.1-git-61-g7bf22e9 >> >> Built fine, but I could not get it running. > > Thanks for the feedback. It was a lack of check in gqrx. You can try > to pull & build again. Much better. The device selection dialog is nice. Works now. Again, could crash it: I started gqrx, run the receiver. When opening the device selection dialog again and selecting the same device with a different sampling rate, the program quits, command line output says: % ./gqrx linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-0-g7f44d838 gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd >>> gr_fir_ccf: using SSE >>> gr_fir_ccc: using SSE Using Volk machine: sse4_2_64 >>> gr_fir_fff: using SSE New filter offset: 0 Hz Loading configuration from: "default.conf" Configuration file: "/home/past/.config/gqrx/default.conf" gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd Using device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) Found Fitipower FC0013 tuner Changing NB_RX quad rate: 96000 -> 1.6e+06 Requested sample rate: 160 Actual sample rate : "160.00" Gain start/stop/rel/abs:-6.3/19.7/0.5/6.7 AVG I/Q: -0.00109374/-0.00117664 AVG I/Q: 0.000537707/0.0022715 [...Lots of following left out: No audio FFT data. AVG I/Q: -0.00246447/2.69753e-05...] Configure I/O devices. AVG I/Q: 0.00371283/0.00201518 CIoConfig : Available input devices: 0 : "Unknown" CIoConfig : Available output devices: 0 : "Built-in Audio Analog Stereo" 1 : "USB Audio Analog Stereo" No audio FFT data. AVG I/Q: -0.00246447/2.69753e-05 AVG I/Q: -0.00109965/-0.00466416 [...Lots of following left out: No audio FFT data. AVG I/Q: -0.00246447/2.69753e-05...] saveConfig Selected output device is 'default' (not saving) Loading configuration from: "/home/past/.config/gqrx/default.conf" Configuration file: "/home/past/.config/gqrx/default.conf" gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd AVG I/Q: -3.42441e-05/-0.00127908 Using device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) usb_claim_interface error -6 Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::runtime_error' what(): Failed to open rtlsdr device. [1]5834 abort (core dumped) ./gqrx selected output device is 'default' (not saving) Loading configuration from: "/home/past/.config/gqrx/default.conf" Configuration file: "/home/past/.config/gqrx/default.conf" gr-osmosdr supported device types: file fcd rtl rtl_tcp uhd Using device #0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) usb_claim_interface error -6 Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::runtime_error' what(): Failed to open rtlsdr device. Backtrace: (gdb) bt #0 0x74613475 in *__GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x746166f0 in *__GI_abort () at abort.c:92 #2 0x74e6568d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x74e63796 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x74e637c3 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x74e63a36 in __cxa_rethrow () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x754a347c in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #7 0x754a8277 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x00418fc7 in main (argc=1, argv=0x7fffdbe8) at applications/gqrx/main.cpp:59 > And yes, good idea to delete old default.conf file. > Also note that saving and loading configuration under different names > is not quite robust yet. Thought so ;-) In comparison to the rtlsdr fork I see you added FM-W. FM-N in comparison sounds more clipped, FM-W is clipped with a narrow filter, but noisy with a wide filter. With a filter that has no clipping, noise is clearly audible. I'm not sure if this is bound by the low dynamic sampling range (8 bit) in combination with big bandwith which means a lot more noise energy with wide filters. Anyway, gqrx gets greater every time! Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
Tom Rondeau wrote on 2012-06-04 14:18: > On Sun, Jun 3, 2012 at 2:22 PM, Patrick Strasser > wrote: >> Hi Tom, >> >> Tom Rondeau wrote on 2012-06-03 17:12: >>> On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser >>> Patrick, >>> >>> It looks like you're problem is in the rational_resampler code. I >>> wonder if there's something about the resampling rate being used >>> that's causing something to go out of bounds here. Can you dig into >>> the code and figure out what interpolation and decimation rates are >>> being used? >> >> Interpolation is 1, decimation is 2. >> Full valgrind log in >> http://pastebin.com/7GCs3bWy > > I was hoping you'd say the interpolation and/or decimation were some > ridiculously large numbers. Since the block is only actually > decimating, could you replace it in the code with an fir_filter_fff > (or fft_filter_fff) just for testing purposes? That'll help us see if > it's the rational resampler itself or something more general. What seems strange to me is the allocation of a buffer of a non by 8 dividable size, that is accessed in blocks of 8 bytes. So the last read always either does not touch the end of the buffer, or it reads beyond the end. I'm a little sparse at time until Sunday evening. I tried to write some mini program starting from dial_tone.cc which uses a filter, have to convince cmake to compile it... learning ;-) Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
Patrick Strasser wrote on 2012-06-03 20:22: > Hi Tom, > > Tom Rondeau wrote on 2012-06-03 17:12: >> On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser >> Patrick, >> >> It looks like you're problem is in the rational_resampler code. I >> wonder if there's something about the resampling rate being used >> that's causing something to go out of bounds here. I'm looking for some test program, that uses C++ and filters/decimators. The only examples in C++ I found are either dialtone, which does no processing, or programs that require some hardware that I do not have (fcd_nfm_rx.cc, Does anyone know of an small GNU Radio C++ application that does some filtering/resampling? Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
Hi Tom, Tom Rondeau wrote on 2012-06-03 17:12: > On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser > Patrick, > > It looks like you're problem is in the rational_resampler code. I > wonder if there's something about the resampling rate being used > that's causing something to go out of bounds here. Can you dig into > the code and figure out what interpolation and decimation rates are > being used? Interpolation is 1, decimation is 2. I compiled GNU Radio branch v3.6.0 with $ cmake -DCMAKE_BUILD_TYPE=Debug .. which resulted in a compile with flags -g -O2 . I tried to track what's happening in gdb, in gr_fir_fff_simd::set_taps, but -O2 was not helping, a lot optimized out, loops unrolled. Full valgrind log in http://pastebin.com/7GCs3bWy regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] crashes, memory errors and valgrind
Hello list, I'm playing around with gqrx, an excellent example which great standalone software can be built with gnuradio. I'm running phirsch's rtlsdr fork, do not have a Funcube Dongle or USRP at hand, but rather a Terratex NOXON DAB stick - 25€ part does the trick fine enough for me ;-) I'm running a self-compiled gnuradio rev3.6.0 on my Debian testing amd64 machine. Sometime it crashes with messages like "glibc detected *** gqrx: corrupted double-linked list". Firing up valgrind on it I find -besides several uninitialized variables- messages of the kind: ==31294== Invalid read of size 8 ==31294==at 0x4F782AC: float_dotprod_sse (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) [deleted some lines...] ==31294== Address 0x1a211ba8 is 440 bytes inside a block of size 447 alloc'd ==31294==at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31294==by 0x4FB3C5E: malloc16Align (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4FB3CA9: calloc16Align (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F75E27: gr_fir_fff_simd::set_taps(std::vector > const&) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) [deleted some lines...] Full trace of that error below, I can provide a full trace of a run if needed. Usually the program runs stable, but occasionally it crashes. I played around with the internal bandwidth to get better FM reception - 75kHz is quite narrow for FM reception. This change seems to trigger the problems much faster. I hardly can change any parameters while running without a crash. I'm no expert, but it seems to me there is not enough memory allocated. Maybe an off-by-one error? Did anyone see things like that or used valgrind recently on gnuradio programs? What could I do to find out more about this problem? Regards Patrick - ==31294== Invalid read of size 8 ==31294==at 0x4F782AC: float_dotprod_sse (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F8A27F: gr_rational_resampler_base_fff::general_work(int, std::vector >&, std::vector >&, std::vector >&) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F45CBD: gr_block_executor::run_one_iteration() (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F65AA8: gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr, int) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F60645: boost::detail::function::void_function_obj_invoker0, void>::invoke(boost::detail::function::function_buffer&) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x52BBCCD: boost::detail::thread_data >::run() (in /usr/local/lib/libgruel-3.6.0.so.0.0.0) ==31294==by 0x81EA928: ??? (in /usr/lib/libboost_thread.so.1.49.0) ==31294==by 0x6C08B4F: start_thread (pthread_create.c:304) ==31294==by 0x76959DC: clone (clone.S:112) ==31294== Address 0x1a211ba8 is 440 bytes inside a block of size 447 alloc'd ==31294==at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31294==by 0x4FB3C5E: malloc16Align (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4FB3CA9: calloc16Align (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F75E27: gr_fir_fff_simd::set_taps(std::vector > const&) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F8A144: gr_rational_resampler_base_fff::install_taps(std::vector > const&) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F8A5B6: gr_rational_resampler_base_fff::gr_rational_resampler_base_fff(unsigned int, unsigned int, std::vector > const&) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x4F8A826: gr_make_rational_resampler_base_fff(unsigned int, unsigned int, std::vector > const&) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294==by 0x44A41D: resampler_ff::resampler_ff(unsigned int, unsigned int) (resampler_ff.cpp:71) ==31294==by 0x44A025: make_resampler_ff(unsigned int, unsigned int) (resampler_ff.cpp:33) ==31294==by 0x4141C9: receiver::receiver(std::string, std::string) (receiver.cpp:80) ==31294==by 0x41DBD9: MainWindow::MainWindow(QString, QWidget*) (mainwindow.cpp:64) ==31294==by 0x41D4D7: main (main.cpp:52) -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM Capture
Am 2011-10-06 12:55, schrieb JOSE FELIX HERNANDEZ BARRIO: > do you know of any radio capture file of the fm band on internet ? > could anyone with access to the required hardware make a capture an > upload it to internet? Have a look at the Wiki and the mailing list archive (hint: Google). There used to be great captures by late Michael Gray, KD7LMO, but these seem to be lost. Anyway there are some samples arround, and if you ask on the list for freshly recorded sample I think you will get some. Does it have to be something special like overlaping stations or big sampling rate/band width? You know, these can get big, like one minute of 16bit/S 512KSps is like 480MiB. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemat_cs_, Graz University of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] searched the mail list but nothing w orks: audio_alsa_sink[hw:0]: Device or res ource busy
Am 2011-09-16 03:26, schrieb king bse: > Thanks, alex. > > I don't know what does "access the ALSA interface with any other audio > application?" mean. > I could run alsamixer and I could listen mp3 using Totem Movie Player on > Ubuntu. > So? Ubuntu usually has Pulse Audio running, which claims and manages the alsa devices. Try default:0 or pulse:0 as device, this is exposed by Pulse Audio as ALSA interface. BTW: If you have problems hearing something, check with alsamixer if all channels are unmuted. Press "s" in alsmixer to select your sound interface. Pulse Audio messes with the ALSA devices and sometimes leaves some channel in a non-favourable state. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio at Chaos Communication Camp 2011
Patrick Strasser wrote on 7/7/2011 10:01 AM: > Is there a village where the probability for meeting GNU Radio people is > extraordinary high? I'll be accommodated in LeiwandVille, which is bordering and in cooperation with HamVillage. Looking forward to see GNU Radio stuff and people! Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio at Chaos Communication Camp 2011
Hello! I'll be attending the Chaos Communication Camp 2011 near Berlin in August[1]. I hope to see some GNU Radio people there. Someone else who intends to be there too? Is there a village where the probability for meeting GNU Radio people is extraordinary high? Regards Patrick [1] http://events.ccc.de/camp/2011/ -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Here's a little beauty
Marcus D. Leech wrote on 7/6/2011 6:12 AM: > If I decimate by 3 or more before the FFT (after vectorizing), I runs > OK, consuming about 40% of the > total system CPU, and not producing any 'O'. Have you tried to find the blocks consuming the power? I once used oprofile, and it worked quite well. You will get a list of functions that consume cycles, by themselves and culminated over all function calls. With that list you can search the source code and find the problematic blocks. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why Isn't GNU Radio Used More? Docs?
schrieb Marcus D. Leech am 2011-05-09 17:12: > The documentation, as Tom observed, is disorganized and incomplete. > This is rather an inevitable result of a system that grows organically > as it has--99% of the contributing participants are largely coders, and > not so much document writers. I don't think that "outsourcing" documentation from coders is the way to go. It's the coders that know about the functionality. They also know the rationale behind the creation a a certain part of the system and all the implementation details: Why was this implemented in this way and not another, what are the strengths, what is important to know, what would be a dis-use of the component, etc. Of course not every coder is a good User Documentation writer. This may be because the coder would have problems to imagine a point of view without all the details he already knows, or he/she is using the system in a very special way, which would be quite different from the mainstream use. So I think the best situation would be to have the coders write API documentation and document design decissions - this could be a text document in the source tree, a blog post or a summary to a mailing list discussion; it should last and be accessible. Then more usage-oriented people with a broader, less detailed view create a users documentation. IMO GNU Radio lacks a lot of low level docs and design docs. Referning to the (undocumented) source code is not documentation. That Howto is a good starter, but I think it does not fit the needs of the average user: Putting blocks together that just work. Sometimes one can find some glimpses of rationales of new features on the mailing list, but in general my impression is that the future design is decided by people off-scene. Just my 2 €-Cent... Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Next Developer's Call RFC
schrieb Tom Rondeau am 2011-02-26 17:57: > We are currently thinking 6 PM > for central Europe, but we would like to hear back from those of you who > are interested in joining this call to let us know your time > availability/preferences. This would be very fine for me in CET, not too early to get home from work and not too late to get some sleep for next day's work ;-) I just have to tame my headset ... Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Moeller on 2011-02-26 13:11: > Sync problems? I thought, the "audio" devices implement > a fixed sampling clock and the USB transmission is buffered to > achieve a continuous stream without gaps or clock variations. > Only the PC audio output has a different clock, but that problem > occurs with other external sources too, like the USRPs. The problem arises between system clock and audio clock. While the Audio clock is most probably a free running clock in the device, the computer may have a slightly different time base. Now who is right about the sampling rate? One thing you can do is accept occasional resyncs with small hickups or clicks, that is some lost samples or some extra samples. Or you can resample the stream, which is computational intensive and decreases quality. Or you manage to synchronize the clocks, which is possible with USB. But the USB clock has probably too much jitter for high quality signal sampling... No easy task. Anyway, refer to SDR widget, they have thought of every possible problem and solution. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Moeller on 2011-02-25 17:36: > On 24.02.2011 15:46, Patrick Strasser wrote: >> Just like every USB sound interface it does not matter where the signal >> comes, where it is going and how things behind the interface work. It >> makes no difference to your application if you connect a converter via >> cable to your sound interface in your computer or if you have the sound >> interface built into your converter. > > But I think it's a big difference in signal quality. For sure. You ged rid of the quality decrease from all the long analog lines. Moreover it frees your computer audio interface for AF input and output. Most computers are not shipped with two audio interfaces. > Do you know the theoretical limits for the sample rate? Common USB Audio adheres to USB Audio Class 1, which was specified for USB 1.1. The data structures allow sample rates to over 4MHz, but USB 1.1 is the limiting factor with its bandwidth: (12MiBit/second)/(16bit/Sample)/(2 Channels)=384kiSPS. That is without protocol overhead, so you can theoretical expect 16bit 192kSPS stereo as maximum. It turns out that not every OS driver supports this data rate, rather 96kiSPS. Moreover you have to deal with different clock speeds and other subtleties. Just putting USB Audio Class 1 on USB 2.0 would not work, because blocks are structured different between 1.1 and 2.0. But back in 2005 USB Audio Class 2 (UAC2) was adopted, offering notably higher sampling rates and bit depths. Apple introduced a UAC2 in Mac OSX 10.6, And Linux has good support since 2.6.34 or .35. Microsoft promised to implement a UAC2 driver for its upcoming Windows incarnations, but nothing on the horizon until now. The SDR widget people sounded every possible combination for the mentioned OSes, with lots of tricks to get the very best out of every driver (especially Windows UAC1). They have different firmware for UAC1 and UAC2. I just read some articles from the SDR widget list and had a conversation with the Linux driver author, maybe I got some details wrong. > Can it fill the full USB bandwidth or does it only accept > "standard audio" sample rates? You can set every integer sampling rate you like withing the capacity limit, but most drivers expect the common sampling rates. The drivers are the limiting factor. And still synchronization of clocks is a big problem. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Moeller am 2011-02-24 00:33: > On 22.02.2011 15:26, Patrick Strasser wrote: > Not exactly. The FCB is not passing the IQ to the analog sound interface. > ADC is done within the dongle and the digital samples are transmitted via USB > to an emulated "virtual" sound card. > > However, for the application it's just another "sound card". Just like every USB sound interface it does not matter where the signal comes, where it is going and how things behind the interface work. It makes no difference to your application if you connect a converter via cable to your sound interface in your computer or if you have the sound interface built into your converter. If it implements the USB Audio Class, its a USB Audio device. A headset works the same. That's the nice thing about abstract interfaces. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Alexandru Csete am 2011-02-23 00:24: > Well, implementing it as UHD device seems a bit overkill from a > programming point of view because one would have to implement the "audio > source", which is readily available in GNU Radio. So a GNU Radio source > just like the old pre-UHD USRP drivers seems to be most feasible. Wasn't there a plan do have some abstract hardware block, that can be _configured_ to use whatever hardware interface that is available, much like the audio interface? It's quite painful to have code bound to some hardware, when all you need is to rename the instantiated hardware block to use other hardware. AFIR some interface was proposed to reflect the capabilities of the interface (tuning characteristics, gain, subdevice selection), which could be set at runtime or from the config files. And of course some logic to automatically select the available device - or the best available device if more than one connected. I think they call it "convention over configuration" and "configuration over code". Just my 2€-Cent Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Alexandru Csete am 2011-02-19 17:46: > On Sat, Feb 19, 2011 at 4:58 PM, Patrik Tast wrote: >> Hi All, >> >> Has anybody tried the FUNCube USB dongle? >> http://www.funcubedongle.com/ >> >> How tricky would it be to add GNU Radio support for it? > > I'm not sure if it makes sense to create a GNU Radio block for this > since the FCD is already an audio source and a block is not necessary > for setting frequency and such. I guess it would still be useful for > using it in GRC applications. I think this would be of great use. The FCB is based on the Softrock DDS design, which evolved to a family of different solutions, with the common factor of a stereo sound interface and a HID interface for control like frequency, source multiplexer switch and filter banks. AFAIK the HID commands are the same in most of these designs. Treating the system as a single interface much like a USRP would get users rid of extra programs and doing things every time over again. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hardware list in wiki
Hello group! I wrote some paragraphs about hardware supported by GNU Radio, which I felt is missing for a long time. It's a draft, no links yet, maybe a little low detailed, etc. I just wrote of what I know is working. If this list is incommplete or incorrect, please feel free to improve it. English is not my first language, so please bear with my style and improver where possible/necessary ;-) http://gnuradio.org/redmine/wiki/gnuradio/Hardware Comments are welcome! Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Increasing ALSA Sampling Rate
schrieb George S. Williams am 2011-01-27 17:38: > Is it possible to increase the maximum sampling rate for audio_alsa? > > I am experimenting with using a modified TV tuner card as an ADC. The > card uses a Bt878a chipset. arecord can record from the card at 1972000 > rate and GRC shows the maximum rate as 1972000, but GNUradio can only > sample at 896000. 896kSPS is quite something. Can you tell more about the hardware? I at least (and probably many others) am very interested in something like this. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FM stereo problem
schrieb Patrick Strasser on 2011-01-25 16:55: > schrieb Bernardo Gonçalves am 2011-01-25 10:15: >> Basically, the problem is that it works just as mono, not stereo... > Second, I looked at your flowgraph. You shift the difference part from > center frequency 38kHz to 0 with the Xlating FIR filter, and then use a > complex-to-float block. This will not result in the positive > frequencies. You'd rather have to filter out the negative frequencies > with a Hilbert transformer, that is a special FIR filter keeping only > positive frequencies, before converting to float again. Sorry, I was wrong. You did the low-pass filtering, that was already right. But two other things I did notice: 1) The difference signal, which is shifted down from 38kHz is several 10dB lower than the sum signal. With different gains I got something more stereo-like. 2) The sum signal is faster than the difference signal. In the diff-signal path you have more blocks that are processed. Some delay (delay block) could maybe fix this problem, but I did not get the right value at a quick try. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FM stereo problem
schrieb Bernardo Gonçalves am 2011-01-25 10:15: > Hello everyone, > > As Euripedes Rocha told few days ago in the email "Who actually *does* > use GNU Radio?", we're starting to use it here, but we do not currently > have daughterboards to use with USRP2. > > Due to this, specially in my case, I'm building some simple diagrams > using GRC, and one of them is a FM stereo transmitter/receiver in the > same flow graph. > > Basically, the problem is that it works just as mono, not stereo... > > Here is a screenshot of the flow graph: > http://dl.dropbox.com/u/8898915/fmstereotxrx.png > > The grc's file is here: > http://dl.dropbox.com/u/8898915/FMstereotxrx.grc First, I like this very much. It's a nice example of how easy it is to implement a system like FM mod/demod in GRC. Did you consider donating this to GNU Radio as a GRC example? I did something similar, just needs the proper docs. Second, I looked at your flowgraph. You shift the difference part from center frequency 38kHz to 0 with the Xlating FIR filter, and then use a complex-to-float block. This will not result in the positive frequencies. You'd rather have to filter out the negative frequencies with a Hilbert transformer, that is a special FIR filter keeping only positive frequencies, before converting to float again. A different way would be to do it analogue to analog (;-)): first bandpass filtering for 38kHz+-15Khz, mixing down with 38kHz to 0 and filtering out the mirror image > 38kHz. The first one should be working much better in a digital complex-valued system. A sample file for testing the graph would be very helpful, with distinguishable left-right channels. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Finally compiled USRP2 code works finewithUDPimage ...but not with compiled Raw Ethernet Image
schrieb Gabriel Morel am 2011-01-17 23:39:
> Do you know how can we share some MS Office files.
That's not so good. First, MS Office files may be practical for you, but
most people in GNU land (and GNU Radio is really GNU) do not have MS
Office or prefer free software alternatives.
Second, MS Office records a lot more information in the document than it
shows when you print it. For privacy reasons, do not share your
documents in this formats in public.
If you need to do it in this form, convert to a more common and privacy
friendly format, like PDF.
> It's easier to
> understand if we can see some commented screenshot in the same document?
Is it really need to take screenshots?
If you have pictures, use a picture format. Add marks for things you
want to show, send the picture with the comments explaining the picture.
Do not forget the comments, a picture alone says nothing.
If you did something on the console, you can copy all input and output
and send it by mail. No need to convert that to any other format.
Tell _exactly_ what you did. If you do not know any more exactly what
you did, try to produce your problem again, this time take notes.
I you used some command on command line ("DOS box"), tell us the exact
command with all parameter, exactly as you entered it. Add the output.
If the output is too long, remove obvious irrelevant parts. You can
replace the removed parts by [...], this makes clear that things where
removed.
If your detailed data is too much for the list (>100 lines or so), put
it at some exchange service. To keep your request understandable in the
future, choose a service which keeps this information for long time.
Then we can still read the thread in 3 years or more.
One suggestion:
http://pastebin.com/
Other ideas anyone?
Take a look at http://gnuradio.org/redmine/wiki/gnuradio/ReportingErrors
Regards
Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser
Student of Telemati_cs_, Techn. University Graz, Austria
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Finally compiled USRP2 code works finewithUDPimage ...but not with compiled Raw Ethernet Image
schrieb Gabriel Morel am 2011-01-17 19:27: > I had try 'make' in commad prompt of windows but 'command not found', i > had try it in cygwin but problem with ise_helper.tcl. I'm trying with > gnumake but I don't understand how to work with it for the moment. I > know you don't have to teach me how to use somethings like this, but do > you have any idea what can I do. It would be easier for all supporting people if you could 'show' what happens. That means: Tell exactly * what you have installed, * where you have it exactly, and * what exactly _is_ working. * Copy the exact commands you enter, * and the output. You will understand that for everyone except you "try it in cygwin but problem with ise_helper.tcl" is not very significant. How should anyone except you know exactly what is going on and causing the problems? You see from the length of the thread that people are willing to help you. You can speed up the process with high quality information. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Low-cost hardware options
schrieb Marcus D. Leech on 2011-01-15 03:10: > I've posted my latest thoughts at: > > http://www.sbrac.org/files/digital_receiver2.pdf I like the design. With an USB2.0 interface it comes close to the FuncubeDongle. > This version has some BOM cost estimates for most of the items, and > shows a new PLL, the ADF4351, which is a new chip from AD, coming out later > this spring, which is pin compatible with the ADF4350, and includes a lower > minimum output frequency, which means extending the range downwards to about > 18MHz from about 68MHz. > Cool. > > Going to a AD6652 (which has built-in DDC and CIC decimators) increases the > price of the ADC by a factor of 3, but it would eliminate the need for a FPGA > on the "host interface" side of that FMC connector. So, you're trading a > more expensive digital-receiver section for a cheaper "host interface" > section. For example, by using an AD6652, one could easily conceive of > nothing more than a cheap EZ-FX2 USB-2.0 implementation on the > host-interface side. > > For at least USB-3.0 and 1GiGe, you pretty-much *need* an FPGA on the > host-interface board to do all the relevant protocol goop anyway, so perhaps > making that FPGA large enough to do DDC and CIC decimation as well as the > "host interface goop" is the right trade-off. You have no host interface. Adding a host interface without FPGA results in the the need for hardware DDC/CIC. An FPGA would add in cost and complexity. One of the Digilent parts could be a starting host interface. A second step could be designing a OS host interface with FPGA, something could imagine quite a lot of people could find interesting. Maybe there are existing designs. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Low cost hardware option
schrieb Marcus D. Leech on 2011-01-13 04:56: > On 01/12/2011 10:46 PM, Brian Padalino wrote: > I'm increasingly liking the approach where you "demarc" at the digital > output of the ADC that I suggested > earlier where you terminate in something like a LPC-FMC connector or > something equally > convenient, which allows you to adapt to various "getting bits to the > host" approaches. > Including: > > o 1GiGe > o USB-2.0 > o USB-3.0 > o PCIe o direct (embedded) Any chance to transfer via eSATA? Quite common nowadays. > But maybe that's the road to *more* expensive, not less (although cost > is only ONE of the factors > of a project like this). First, price is one constraint, or one of the features, that would make such a device attractive to a wide audience. Others would be flexibility, simpleness, that is fitness for home building, capabilities: lowest/highest frequency, dynamic range, simultaneous bandwidth, DDC, filtering, FPGA; RX only vs.s RX and TX; interface and others. For price: I'd say 200$-300$ for a tunable frontend, 16bit resolution, >500kSps and flexibility to support IF input, clock input, digital stream output (for other transport/consuming system) DIY-kit is attractive. If the flexibility is not available, this would be to expensive. Phillip Balister tried to connect a USRP to a Beagle Board, which was not so easy because the USRP hat no way to tap the data between the FPGA and the USB interface. For flexibility, being able to bypass stages or feed signals e.g. at the ADC would be cheap. Preparing for different transport systems would make it more future proof. If USB3.0 hardware support is not satisfying now, maybe it is in two years. For the data bus part this would require a prepared interface for data and control lines. I see the target for such at above all the soundcard solutions and below the USRP1. USRP1 can do 8MHz Bandwidth complex at 14bit/sample RX, which is more than enough for hobbyists. What would be interesting for university teaching and research? What would be interesting for other potential users, like hams? Did I miss some? USB3.0 is common at new high end PCs and Laptops, ExressCard at Laptops. Of course every PC with PCIe is ubgradable to both of them, but it's extra money to spend and extra hassle to get it started. I do not see urgent need for such extreme data rates. This could be a second step. For a start, a not too expensive, but still capable system with options for extension seems most doable for me. If the transport systems is to be fully integrated in the first shot, at least the data should be accessible via some interface. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] line codes and FSM/Trellis
Hello List! Half a year ago I read about Miller/Delay coding. Achilleas Anastasopoulos wrote[1] that this encoding can bescribed by a FSM (finite state machine) and decoded with a trellis decoder. Now it would be great to have GNU Radio capable to decode any given line code, framing, convolution, interleaving, FEC and whatever stop or procedure common nowadays. We have some framers, FEC blocks, differential blocks, framers/deframes, clock recovery. I'm interrested at first in line codes. Now what I wonder is: Can every common line code be represented by a FSM? Can every common line code be decoded by a trellis decoder? Can anyone give me a pointer for literature? What would be the easiest way to implement a _encoder_ in GNU Radio. Regards Patrick [1] http://thread.gmane.org/gmane.comp.gnu.radio.general/27540/focus=27555 -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematics, Graz University of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: "Open-Hardware"
schrieb Marcus D. Leech am 2011-01-12 02:40: > Well, I *personally* don't care very much about random-disk-noise, errr, > I mean Windows, > but I'm sure others do :-) There is a lot of people outside the Linux world, especially in the non-academic hobbyist corner. These people seem to me to try to work with least possible changes, that is install no new OS, install no additional tricky exotic drivers, and at most plug in some USB device. That's perfectly ok for me. If these people should be serverd as well you unfortunately _have_ to to think about Windows, as hard and painful as it may seem. >> I read the UAC1 specs a year ago and thought "Great, you can advertise >> up to 4MSPS on USB Audio!", but it turned out that it was specified for >> USB 1.1, which just cannot handle the data rates. :-( Then I found the >> SDR Widget, and they really get everything out of the Windows UAC1 >> driver. >> >> > I thought you couldn't do more than 48Ksps with UAC1, no way no how. You can trick Windows to do 192Ksps via UAC1, I think. No sure if its 16 or 24 bit. > Perhaps I should read that spec again, but it seems that UAC2 is the > way forward, with 384Ksps audiophile DACs using UAC2 already becoming > available. I can think of a way how the SDR Widget people do it: Different firmwares for UAC1 and UAC2. With a third for a more generic interface, this could be compatible and fun at the same time. > An interesting device is the AD6655, which is an integrated ADC and > signal processing chain (complex DDC, and one or more CIC decimators > and FIR filters). Now that is not exactly the cheap one, but with its 150MSPS it would be quite a frequency range with low additional effort. What would be the goal for such a device? Which bandwidth are of interest, which dynamic ranges? Which frequency ranges? Extra frontends? IF from other transceivers or transverters? What would you do with it? Oh, I forgot one interesting device: http//:www.websdr.org/ Seems the hardware info is not linked any more, but its a DDS board with Ethernet interface. Very application specific, but all soldered by hand. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: "Open-Hardware"
schrieb Marcus D. Leech on 2011-01-12 01:44: > Another thought I had earlier today is that with UAC2 (USB Audio Class > version 2), there's no limit on the sample rate that a UAC2 device > can advertise, so it might be nice to make a USB-SDR device "appear" > to be a UAC2 compliant device. [Well, OK that's not strictly > true, you can advertise up to something like 400Msps]. > > Perhaps we can overload the control interface a bit (volume control > becomes RF gain, use some other thingy in the control portion of > UAC2 for setting frequency). You just ad a second interface that is HID, which is available on every platform and easy to handle. That's how all the soundcard-like DDS do it. The only problem is that Microsoft promised in 2005 to implement UAC2, but "forgot" to do it until now. BTW they have a big mess with USB, as Daniel Mack, Linux UAC2 author wrote: "Inevery cruel reincarnation of their OS, it has different issues." I spare you the terrible details an leave out the rest of his summary. I read the UAC1 specs a year ago and thought "Great, you can advertise up to 4MSPS on USB Audio!", but it turned out that it was specified for USB 1.1, which just cannot handle the data rates. :-( Then I found the SDR Widget, and they really get everything out of the Windows UAC1 driver. Regards Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: "Open-Hardware"
schrieb Marcus D. Leech on 2011-01-12 01:16: > For certain classes of high-bandwidth applications, you're willing to > sacrifice > number of bits for bandwidth. For sure. But you have to commit that your usecase is more the corner case then the mainstream. With your CPLD mentions below this should not be a big deal. > the FX2 has an external FIFO interface, intended to handle storage > devices, but interfacing to a high-speed > dual-channel-simultaneously-sampled ADC shouldn't be that hard--might > require an uber-cheap CPLD to > handle some of the handshaking. AFAIK the SSRP is just shoveling bits from the ADC to the FX2. >> An other way would be to change the interface, which would very likely >> be Gigabit-Ethernet. >> >> > I haven't found a "cheap" way of doing GiGe. GiGe is for high end. It adds comlexity on the network and host side (configuration...) and is IMO unnecessary. Of course you get speedup by 2.5 over USB, but as ham and hobbyist you hardly need all the USB capacity. What I'd like to have is something like the Digilent Basys2/Nexys2. A capable USB interface, some CPLD/FPGA for the hard stuff, maybe a microcontroller, some memmory, buttons, 7-segment-display, and connectors like SD card etc. With examples and modules like for the Digilent parts this would make it easy to start all kinds of projects. The board are already cheap, but not OS. If it was compatible with the PMOD module, this gave a good starting point for working strait and for custom modules like the Charleston SDR. If people agree on a bus, modules could be stacked: AD module, mixer module, filtering module, LNA or transmitter module. Regards Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] "Open-Hardware"
First, let's change the topic. This is overdue. schrieb Moeller on 2011-01-11 07:21: > On 10.01.2011 02:22, Marcus D. Leech wrote: >> The SSRP, as far as I can tell, is dead. Last status update was nearly 4 >> years ago. > > The development stopped apparently. But at least he has a working design for > the RX part. > >> o The ADC board (single-channel, thus cannot handle direct-conversion with I >> and Q sampling) $120.00 >> o Uses an Off-The-Shelf ElraSoft FX2 board, which in 2007, sold for $89.00 > > Oh, forgot about the USB interface, so it's about $200. That would be my > limit for a home-product. As I said before, I think the Elrasoft board is more than completely overpriced. There must be something cheaper out there. Or it has to be created. I could imagine that an Open Source EZ-FX2 with voltage regulator and a set of sensible connectors would be a great tool for a lot of people. For comparison: The Arduino costs like 25€ nowadays. Recently they changed their USB interface from a limited dumb FTDI to a Atmel USB microcontroller Atmega8U2. The Arduino can now act not only as a serial divice, you can make it look like lot of things: HID (mouse, keyboard, joystick), mass storage, audio device, MIDI interface, most of them host and device. http://arduino.cc/en/Main/ArduinoBoardUno http://www.fourwalledcubicle.com/LUFA.php >> Ok, so maybe we can run the ADCs and DACs at a lower rate, so that we can do >> the DDC and decimation in the FX2? I'd be >> *astonished* if it could keep up with input rates beyond roughly about >> 200Ksps complex, which is cheap sound-card territory. Oh dear. > > Not if a modern PC with appropriate programming (SSE extensions) would do the > decimation. You need the decimation on the device side of the USB connection to reduce the amount of data sent over it. The absolute limit isbetween 32 an about 40MiByte/sec. Divided by 16bit=2byte per sample is 16-20MSPS real-valued or 8-10MSPS complex-valued. Either you reduce the sampling rate or you decimate. That rate should be more than sufficient for all but the most demanding experiments. The only common interesting signals that need more bandwidth are TV (6-8MHz), GPS (2-20MHz?), WLAN (20MHz), All of them in higher bands, where mixing the signal down into the ADC frequency range would be needed. An other way would be to change the interface, which would very likely be Gigabit-Ethernet. Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB
schrieb James Hall am 2011-01-11 13:16: > > It's not much for the tax-payer or commercial clients. > > Why should that be? > > I'm not the guy you're replying to but you know you kinda cut this > thought in half and replied to it out of context. "It's not too > expensive for the tax-payer or commercial clients, But it's a lot for a > hobbyist" Sorry, I read "It's _more_ for the tax-payer or commercial clients." I got it wrong. > Why is it that the USRP was $450, then discontinued to bring out the > USRP2 for $700 now it's being discontinued for a new design that will be > marketed at $1700? I see all three available. The USRP2 is not a replacement, but rather an additional choice for different requirements. Same for the USRP N200. > It's what they dig out of the couch cushions. That or hams that can > afford luxury radios in the $2-4k+ range. USRPs are not the cheapo DIY kit hardware for small experiments. It's rather very capable hardware for a fair price with flexibility that other systems can not offer. If you want that range of capabilities you have to pay the price. If you do not need that much, you will probably better served by an SoftRock and Soundcard. If you want it especially for hams, compare these: QuickSilver QS1R Receiver http://www.philcovington.com/QuickSilver/ Perseus http://www.microtelecom.it/perseus/distributors.html Flexradio Flex 1500 or Flex 3000 http://www.flex-radio.com/ ICOM 9100 http://www.icomamerica.com/en/products/amateur/hf/9100/default.aspx RF-Space SDR-14 http://www.rfspace.com/RFSPACE/SDR-14.html These are all great devices and sold as amateur radio equipment. Not all hams and DIYs are young and have no money for expensive hardware. Some people like to spend all their extra money in cars, some in new TV sets (I saw people buy TV systems for >5000€ in less than half an our...), some enjoy their holidays in exotic locations, some by ham equipment. On the other side there are hams that build all there equipment themselves with low budget and low power, and still do great things. If your requirements exceed your budget you can at least modify your requirements easily to get them matching. Or you can spend some extra cycles of your free brain power on it and maybe get a clever solution ;-). Fortunately out there exists a big range of different devices for all kind of funds. A good compilation of SDR systems from cheap to expensive can be found at http://f4dan.free.fr/sdr_eng.html Regards Patrick PS: More links can be found on http://www.delicious.com/trapicki/sdr -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB
schrieb Moeller am 2011-01-11 07:59: > On 11.01.2011 04:24, Marten Christophe wrote: >> matured that time. USRP has been sold in $450 , how one can claim >> proprietorship on a product which was develop as open sourced >> hardware project. many of people have contributed to it on Mr. Ettus > The copyright is at Ettus. The schematics are freely available, you can produce the PCBs for an USRP yourself. > It's not much for the tax-payer or commercial clients. Why should that be? > But it's a lot for a hobbyist. > Why can't there be a open-source community version of a Gnuradio-Hardware, > about $200 for the material, do-it-yourself assembling, some performance > tradeoffs (no expensive MIMO connector, cheap FPGA variant) etc. ? If you want the same performance like the USRP (64MSPS, 14bit, FPGA, USB, connector/daugterboard system, TRX), you will have to pay the price. If you can live with less there are options. If you want to start something new, send your proposal, you'll be gladly supported by lots of people. Please keep in mind: Engineers motto: cheap, good, fast - choose any two ;-) In other words: A DIY kit is not just the BOM/BOM costs. Its development time and failed attempts, production costs for a PCB, risk margin for unsold kits, extra costs for parts in batch amounts (you want just 3, we only sell it by 25...), shipping costs, packaging, tax/custom. If you find someone who does all that for free, what are you willing to give back? > This is a RX-only SDR with all relevant design files > (Schematics, PCB, Gerber), BOM about $200 : > http://sdrtrack.drupalcafe.com/?q=node/2 That's the Charleston SDR. http://www.amrad.org/projects/charleston_sdr/ The creator is a nice person, if you ask for permission you have chances to build your own. The AMRAD people have done several batches of this system already for workshops. ~100$ for the Digilent Board, ~100$ for the SDR board. The Digilent part is good for a lot more fun, too. NB: John Schwacke, the creator of the board, has already built a GNU Radio block for this. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Alternative Hardware [was: Re: A Humble Request.... - "Open-Hardware"]
[Please! Möller, add a one line before and after you text, reading your replies is really a pain.] schrieb Moeller am 2011-01-09 18:07: > On 09.01.2011 05:48, Brian Padalino wrote: >>> Hello Mr. Ettus, >>> Do you have any plan to reduce price for USRP1 or release PCB layout for >>> poor students? >> So lets figure out something that is worth while for you to do - >> simulate something. Simulate anything! There is a channel simulator >> built into GNU Radio. Use it. Get familiar with it. Familiarize > He didn't ask for a simulator, he asked for real hardware. He did not back his request with some deeper insight why he exactly needs this thing except for he wants it and has not enough money to buy it. We do not know what he wants to accomplish, and how he thinks to get there, what he already did. This would be very valuable information - There are people around who could show alternatives that are easier to get or cheaper/free, and some people have set up USRPs to be used by other people. If you need off-the-air samples, some can be found already online, or maybe someone is willing to record some special signal for offline use on request. Having a transmit capability is one really not replaceable capability, but first that's quite at the end of the things to do, and second you can easily run in problems with frequency licence regulations. Moreover having an USRP is just half of the bill. The RF front-ends are necessary too, and if you want one of the more advanced, you want get far with <100$. Compared to other systems that's still cheap, but not for free. I agree with Brian, there is plenty of things that can be done without (expensive) hardware. > I saw some simpler approaches with a sound card. But that's really > narrow band. Not very much for a spectrum analyzer. > The SSRP approach seems to be more interesting: > > http://oscar.dcarr.org/ssrp/ > > It has a 15 MS/s ADC, 40 MS/s DAC, he counts $120 for the ADC board. > There's software to interface with Gnuradio. Last time I asked David Carr had not time/interrest in continueing the project. IMO the Elrasoft Interface board is ridiculous expensive. Its merely an Cypress EZ-USB FX2 with some voltage regulators for 89$. I think it was a good start, but there are other more promising parts worth investigating: * Have a look at Digilent [1] Basys and Nexsys boards. You get the same interface chip as the USRP, which should give a good start for firmware development, and a FPGA, switches, buttons, displays, connectors (VGA/PS2 etc.) for about the same or less price. Academics/Students get it cheaper. Moreover Digilent offers a number of modules to connect, with examples and schematics. If you really want high sampling rates and frequencies, have a look at the Charleston SDR [2]. * One interresting RX interface coming up these days is the FuncubeDongle [3]. Unfortunately it's under a NDA spell, but the thingy rocks. Hopefully the next batch will not be sold out in seconds. * The Icom PCR1000 [4] is a commercial part with great frequency range. ZFs at 10.7MHz and 450kHz exist, so maybe you can connect it to some other standard hardware to do some great hacks and get RF OTA very cheap. * If you have equipment to bring your signal down to baseband there is nothing more promising than the SDR Widget [5][6]. They target USB Audio usage, at 24 bits/192kHz, which should be quite sufficient for a number of things to try. They claim to beat most of the commercial high end PC sound interfaces in signal performance. You see, there are quite some parts for ~100$ as alternative to USRPs. Hardware exists, software is cheap if you have time and skill, as J.D. Baker explained. If you do not have the skill, you still can learn ;-) Regards Patrick [1] https://www.digilentinc.com/ [2] http://www.amrad.org/projects/charleston_sdr/ [3] http://www.funcubedongle.com/ [4] http://shop.ebay.com/i.html?_nkw=icom+pcr [5] http://code.google.com/p/sdr-widget/ [6] http://groups.google.com/group/sdr-widget -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Building gr-uhd: .Tpo file not found/Permission denied
schrieb Josh Blum on 2011-01-09 04:29: > Its nothing special, you probably just did sudo make command and got > something with root permission. Make sure that your user has permission > on all the files, worst case scenario, git clean and rebuild. You are right, thanks. For some strange reason gr-uhd/lib/.deps was owned by root:root. I think I ran sudo make install when the tree was not built. This triggered a regular build, wich started with 'make dep', wich generated root wowned .dep-directories. sudo make distclean was the solution. Regards Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: using rsh from a remote host
schrieb Sangho Oh on 2011-01-09 23:30: > Actually, same result for ssh and rsh. > I have log in and run the script. > Otherwise, (if I run the scrip from remote host) > gnuradio transmission does not work. Ok. Can you explain a little bit more detailed what you want to do, what you did exactly, what was printed exactly (with some preceeding lines etc.) and your setup: OS/Distribution, versions of programs used. If unsure, refer to [1]. Patrick [1] http://gnuradio.org/redmine/wiki/gnuradio/ReportingErrors ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: using rsh from a remote host
schrieb Sangho Oh am 2011-01-09 06:39: > Hello, > > If I use rsh from a remote host Is there any reason not to use ssh? It is well known and secure. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: D-Star with gnuradio?
schrieb Rafael Diniz on 2011-01-09 03:56: > Hi Patrick, > Thanks for the answer. > I know about codec2, but how about what modulation to use? > I read about the AOR ARD9000MK2[1] modem, that uses the: > "G4GUO open protocol". > Do you know if is possible to implement this OFDM based one? Unfortunately I could not find any document that describes the G4GUO protocol. Would be very interested too. >From http://www.aorusa.com/ard9800.html I got: Modulation method: OFDM Band width: 300 Hz - 2500 Hz, 36 carriers Symbol Rate:20 mS (50 baud) Guard interval: 4mS Tone steps: 62.5 Hz Modulation method: 36 carriers: DQPSK (3.6K) AFC:+/- 125 Hz Error correction: Voice: Golay + Hamming Video/Data: Covolution + Reed-Solomon Header: 1 Sec. 3 tones + BPSK training pattern for synchronization Digital voice: AMBE2020 coder, decoder Signal detection: Automatic Digital detect, Automatic switching between analog mode and digital mode Video Compression: AOR original adaptive JPEGFrom Seems not too far off to implement in Gnu Radio/USRP. Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building gr-uhd: .Tpo file not found/Permission denied
Hello! I just tried to build gr-uhd, and got this error: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I/home/past/src/gnuradio/gnuradio-core/src/lib/runtime -I/home/past/src/gnuradio/gnuradio-core/src/lib/general -I/home/past/src/gnuradio/gnuradio-core/src/lib/general -I/home/past/src/gnuradio/gnuradio-core/src/lib/gengen -I/home/past/src/gnuradio/gnuradio-core/src/lib/gengen -I/home/past/src/gnuradio/gnuradio-core/src/lib/filter -I/home/past/src/gnuradio/gnuradio-core/src/lib/filter -I/home/past/src/gnuradio/gnuradio-core/src/lib/missing -I/home/past/src/gnuradio/gnuradio-core/src/lib/reed-solomon -I/home/past/src/gnuradio/gnuradio-core/src/lib/viterbi -I/home/past/src/gnuradio/gnuradio-core/src/lib/io -I/home/past/src/gnuradio/gnuradio-core/src/lib/g72x -I/home/past/src/gnuradio/gnuradio-core/src/lib/swig -I/home/past/src/gnuradio/gnuradio-core/src/lib/hier -I/home/past/src/gnuradio/gnuradio-core/src/lib/swig -I/home/past/src/gnuradio/gruel/src/include -I/home/past/src/gnuradio/gruel/src/include -I/home/past/src/gnuradio/volk/include -I/usr/include -I/usr/local/include -I/home/past/src/gnuradio/gr-uhd/lib -g -O2 -Wall -Woverloaded-virtual -pthread -MT uhd_multi_usrp_source.lo -MD -MP -MF .deps/uhd_multi_usrp_source.Tpo -c uhd_multi_usrp_source.cc -fPIC -DPIC -o .libs/uhd_multi_usrp_source.o uhd_multi_usrp_source.cc:187: fatal error: opening dependency file .deps/uhd_multi_usrp_source.Tpo: Permission denied compilation terminated. make[3]: *** [uhd_multi_usrp_source.lo] Error 1 make[3]: Leaving directory `/home/past/src/gnuradio/gr-uhd/lib' Seems like the file does not exist: $ ls -1 gr-uhd/lib/.deps/ uhd_multi_usrp_sink.Plo uhd_multi_usrp_source.Plo uhd_single_usrp_sink.Plo uhd_single_usrp_source.Plo What I did: === Build UHD acording to the UHD Manual[1]. The UHD wiki[2] says I should take the "next" branch: git branch --track next origin/next git checkout next Then I pulled the last changes: git pull Built gnuradio: ./bootstrap && ./configure --disable-gr-sounder --disable-gr-trellis --disable-gr-video-sdl --disable-gr-radio-astronomy --disable-usrp2 --disable-gr-usrp2 --disable-gr-atsc --disable-gr-msdd6000 --disable-gr-gsm-fr-vocoder --disable-gr-noaa --disable-gr-pager --disable-gr-radar-mono --disable-gr-gpio --disable-gr-cvsd-vocoder --disable-gr-audio-jack --disable-gr-audio-oss --disable-gr-audio-portaudio --disable-gr-gpio && make configure did not report any errors AFAIKS. About gr-uhd it says: checking for UHD... yes Component gr-uhd passed configuration checks; building. I googled for the error message, and found something about quoting problems in automake 1.9[3], but the paths and filenames seem to be not exotic or worth quoting. What I use: Ubuntu 10.10 Maverick amd64 with some mixed-in Debian unstable $ libtool --version ltmain.sh (GNU libtool) 2.2.6b $ automake --version automake (GNU automake) 1.11.1 $ git name-rev --name-only HEAD next $ git describe v3.3.1git-831-gbb438e7 UHD version is 0001.20101231183142.b4d58f3 UHD: $ git log |head -n 3 commit b4d58f3501596fdddf240d576d0b1b2cb5862892 Author: Nick Foster Date: Fri Dec 31 10:31:42 2010 -0800 Maybe I'm on the wrong branch? Regards Patrick [1] http://www.ettus.com/uhd_docs/manual/html/build.html#build-instructions-unix [2] http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki/#Gnuradio-UHD [3] http://thread.gmane.org/gmane.comp.sysutils.automake.general/7661/focus=7670 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: D-Star with gnuradio?
schrieb Rafael Diniz on 2011-01-08 03:30: > Hi people, > Have anyone successfully built a D-Star transmitter with gnuradio blocks? For the protocol part, see the archives[1]. IMO D-Star is a thing to make money rather than a system to foster independent communication. There are legal, privacy and free implementation issues. For the codec parth D-Star uses AMBE+ as codec, which is non-free. You can buy codec ICs, but you cannot implement it in Open Source. See the archives again for a discussion. Have a look at "codec2" [2], this should work fine for quite the same requirements: low NF bandwidth, low bitrate, low latency. Regards Patrick [1] http://search.gmane.org/?query=%22d-star%22&author=&group=gmane.comp.gnu.radio.general&sort=relevance&DEFAULTOP=and&xP=d%09star&xFILTERS=Gcomp.gnu.radio.general---A [2] http://www.rowetel.com/blog/codec2.html [3] http://codec2.org/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: How the valve block works
schrieb Josh Blum am 2011-01-08 05:29: > >> Just found out that the selector block fits my requirements much better. >> But do I have the same behaviour here again? >> > > The valve is implemented with the selector. Thanks. What would be the best way to disable a branch of the flow graph, so that the disabled path is stopped/starved/drained/disabled? I do not care too much about stale data in buffers, I just want to get rid of the unnecessary processing power that is consumed by the path branch. If this is not possible in grc, I'd take the generated source and modify it, no big deal. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: How the valve block works
schrieb Josh Blum on 2011-01-08 01:44: > The input blocks to the valve, when open, connect to null sinks. The > idea was to drain any incoming data. This could be desirable if for > example you had other blocks, like a file sink that also used this > stream. You wouln't want to back-up indefinitely and then consume all > the old data when closed again. It depends on the topology. So maybe the > user should decide... > > I think the valve needs a user-set policy. Consume when open, or block > when open. And while we are at it, for the outputs, produce zeros when > open, or block when open. Just found out that the selector block fits my requirements much better. But do I have the same behaviour here again? I replaced my const multipliers/adders with selectors, but now it uses much more cpu load :-( Regards Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How the valve block works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I'm trying to implement an application with GNU Radio Companion that incorporates different branches. For example I have a Wav source and a signal source and I want to switch between them. Or I want to hear the signal at socertain points in the flow graph. The old way was to use a variable chooser, const multipliers for muting of paths and adders. The downside of this system is that all the paths continue to run concurrently. I do not use the muted paths, but they still consume processing power. Now I found the valve block, and the doc says: Connect output to input when valve is closed (not open). I expected the valve to block when input is not connected to output. I thougth the flow graph would starve/block on that path. In consequence the path would not consume processing power. Now it seems - referring to Josh's message from 2010-05-06 [1] - that down the path from the valve indeed starving happens, but the null sink in the valve happily consumes, keeping the producers running. I thought about replacing the null sink with something blocking. This would for sure work with otherwise unconnected sources, like when choosing between different sources. But I'm not sure what happens if the path splits before the valve. Would the blocking be propagated back over the split or be limited to the path with the valve? Maybe I'm just on the wrong track and there is some other simple solution for this problem. Regards Patrick [1] http://article.gmane.org/gmane.comp.gnu.radio.general/26777 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nrBYACgkQ/G6gHctkMa/WtQCfV6z15+BrBgPa12X/WCoCphXt jqUAn0fSxmm94i/OS/FXKa/cC1E0cX8e =Jn5p -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Stow and make install (DESTDIR)
schrieb Alexandru Csete on 2011-01-06 21:09: > Hi Patrick, > > I manage multiple versions of GNU Radio manually by simply installing > each under its own prefix and having a symbolic link "current" point > to whichever version I want to use. We should document both ways in the wiki. Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Stow and make install (DESTDIR)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 schrieb Alexandru Csete on 2011-01-06 21:09: > Hi Patrick, > > I manage multiple versions of GNU Radio manually by simply installing > each under its own prefix and having a symbolic link "current" point > to whichever version I want to use. It is really easy: > > 1. Update local repository using "git pull" > 2. Get unique version for the snapshot "git describe --abbrev=8" > This gives something like v3.3.1git-817-g66768f6e That was the part I missed until now. Thanks! > 3. Build and install GNU Radio using > --prefix=/opt/gnuradio/v3.3.1git-817-g66768f6e > 4. In /opt/gnuradio create a symlink pointing to the new version "ln > -s v3.3.1git-817-g66768f6e current" > > I have my environment set up to include the stuff in /opt/gnuradio/current: > > export PATH=$PATH:/opt/gnuradio/current/bin > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio/current/lib > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio/current/lib/pkgconfig > export > PYTHONPATH=$PYTHONPATH:/opt/gnuradio/current/lib/python2.6/site-packages I could not get all the paths right, and I like things in /opt less than in /usr/local as you have to care yourself to get it known to the rest of the system. But in the end its a matter of taste. Regards Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0mKYsACgkQ/G6gHctkMa8VOgCcC7KCkmqLWWsatJzeVH3x0ODc mTEAoKLRcTEiTmBIpLNnLQdSe7C/B5JN =WepS -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Stow and make install (DESTDIR)
Hello!
I tried to install GNU Radio with GNU Stow. I'd like to have several
versions of GNU Radio that I can switch betwenn without rebuild. Stow
seems to help much in that scenario. And it does a clean uninstall even
if the build tree has changed since build.
How install does _not_ work:
The Stow manual recommends[1]:
6.1.2 Other FSF software
The Free Software Foundation, the organization behind the GNU project,
has been unifying the build procedure for its tools for some time.
Thanks to its tools `autoconf' and `automake', most packages now respond
well to these simple steps, with no other intervention necessary:
./configure options
make
make install prefix=/usr/local/stow/package
Hopefully, these tools can evolve to be aware of Stow-managed packages,
such that providing an option to `configure' can allow `make' and `make
install' steps to work correctly without needing to "fool" the build
process.
Unfortnately libtool does not like this way of installing:
$ make install prefix=/usr/local/stow/package
[...]
test -z "/usr/local/stow/packag/lib" || /bin/mkdir -p
"/usr/local/stow/packag/lib"
/bin/bash ../../../libtool --mode=install /usr/bin/install -c
libgnuradio-core.la '/usr/local/stow/packag/lib'
libtool: install: error: cannot install `libgnuradio-core.la' to a
directory not ending in /usr/local/lib
[...]
How install _does_ work:
You rather need to install with DESTDIR[2]:
# full version
STOWDIR=/usr/local/stow
PACKAGE=gnuradio
VERSION=3.3git
PREFIX=/usr/local
./configure --prefix=${PREFIX}
make
sudo make install DESTDIR=${STOWDIR}/${PACKAGE}-${VERSION}
stow -d ${STOWDIR} -t / ${PACKAGE}-${VERSION}
Note: make install with DESTDIR installs everything with DESTDIR
prepended. If PREFIX=/usr/local/, and DESTDIR=/usr/local/stow/package,
files will end up under /usr/local/stow/package/usr/local/. Stow just
moves files out of DESTDIR to the target directory. This is why the
target has to be /-
If you install to the standard paths, this can be simplified to
# simple version
PACKAGE=gnuradio
VERSION=3.3
./configure
make
sudo make install DESTDIR=/usr/local/stow/${PACKAGE}-${VERSION}
sudo stow -d /usr/local -t / ${PACKAGE}-${VERSION}
If you get conflicts you probably have an old package version installed.
You need to uninstall first.
Uninstall:
==
List your stow packages:
STOWDIR=/usr/local/stow
ls $STOWDIR
The name of the directory is the name of the package.
Unstow the currently installed version:
sudo stow -d $STOWDIR -t/ -D package
[1] http://www.gnu.org/software/stow/manual.html#SEC8
[2] http://www.gnu.org/prep/standards/standards.html#DESTDIR
I hope this information can help others manage their GNU Radio
installations.
Regards
Patrick
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] HF 6596.3 HF- 1215 PV Dokumente-Fehler nach UTF-8-Umstellung fertig!
Hallo Deployment! Hab gerade einen Hotfix fertig. Sind zwei Reports, Einspieldauer < 1 Minute. Einspielen im Betrieb möglich. Dringlichkeit nicht extrem hoch, also kein Extratermin nötig. Schönen Gruß Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: HF 6596.3 HF- 1215 PV Dokumente-Fehler nach UTF-8-Umstellung fertig!
schrieb Patrick Strasser am 2010-10-29 15:57: Sorry, something in the wrong list. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP2 FM TX and FM RX working together
schrieb Jorge Miguel am 2010-09-22 13:10: I forgot to mention, but I get a lot of messages like: .SSS SSaUSSS. I did the calculations and with the 104 interpolation USRP sink and 208 decimation USRP source and 16 bits per sample means that less than 100Mbs are taken from the 1Gbps ethernet wire. So there souldn't be any overload. Connection capacity is not the problem, but consuming the data. GNU Radio has no intrinsic concept of sample rate. It processes data in pipes as far as possible and blocks when sources do not provide data or sinks do not consume data. The blocks are connected by buffers that are not infinite in size. If your input rate (Ethernet) does not match your output rate (Audio), at some point either the buffers are all empty (underrun) or all buffers run full (overrun). This is the point where you get notifications in form of S, aU, aO, etc. It is your task to calculate the data/sampling rates correct and convert rates with resamplers. Maybe you want to have a look at the example FM receiver and compare your rates with the ones used there. Furthermore I still don't know why is necessary the multiply cont block in the modulator. This is your volume/gain knob. In GRC you can connect it to a slider and try different values in real-time. Depending on your sink data type (complex, short) you have different ranges for full scale signals. Generally you would want to scale your signal nearly to the maximum amplitude to use the full precision, especially when working with non-floats. -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio & USRP help reveal Security and Privacy Vulnerabilities of In-Car Wireless Networks
Hello! FYI: Just found an article at a German computer news site (Golem)[1] about a paper by Ishtiaq Rouf and Rob Miller from University of South Carolina and Rutgers University about Security and Privacy Vulnerabilities of In-Car Wireless Networks[2]. They used GNU Radio and USRP to record the traffic between the tire pressure sensors and the car. Patrick [1] http://www.golem.de/1008/77111.html [2] http://www.winlab.rutgers.edu/~Gruteser/papers/xu_tpms10.pdf -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: how to find local peak of sinc function ? peak detector setup ?
schrieb grc007 am 2010-06-17 23:28: Hello, I need again your help for this problem: - I want to locate the peaks (local maximum) of the input signal, which is sinc-function pulse (the 2 gray points in picture sincpuls.png, not the neighbour peaks). How can I use the gr_peak_detector in grc to do this ? If you know the exact shape of the signal you want to detect, you may get better results with doing a correlation with the desired signal first. Then you can use a threshold or a more sophisticated peak detector. - If you look at my grc-picture (peakfalse.png) you will see that the peaks are not at the right places. They happen before the true peaks of the sine-function. You did not show the complete flow graph in your pictures, but chances are good that its not early, but late. Both the FFT sink and the peak detector need some time for processing reulting in some delay so you must not expect their output to be synced. You need to find out somehow both delays, or at least the difference of the delay. Try you flowgraph with other imput signals, like ramp. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: alsa device numbering
dave k wrote am 2009-12-08 23:28: hey folks im not too familar with the alsa device number scheme or where this info is stored. i think there is a /proc/ that will show me something like this but i cant find it device 0,0 card a output a device 0,1 card a input a I'm missing a exact question, so I guess: Q: Where do I find the device names that ALSA knows of? A: Try 'aplay -l'. This should give you some things you can try out. If your card is not supporting your desired smapling frequency and you were using hw:x.x, try hwplug:x.x instead. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: DeepSec - OpenBTS in Wien - please ignore
Patrick Strasser wrote am 2009-09-14 21:10: Hallo Alex! Sorry, obviously wrong address... Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DeepSec - OpenBTS in Wien
Hallo Alex! Hab gerade folgedes gelesen: http://openbts.blogspot.com/2009/08/gsm-security-workshop.html 17.-20. November Wollte immer schon was über das Air-Interface Um von 'GSM wissen, aber mir fehlen gerade die 700€ für die Vorträge. Aber wäre schon cool Hararld Welte und David Burgess zu treffen und mit denen zu plaudern... Schönen Gruß Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problems with GNU Radio
Robert and Millie wrote am 2009-09-09 04:47: This the error I received when testing the GNU Radio installation after the make file finished running. I have Boost 1.38 loaded along with GNU Radio version 3.2 and wxPython version 2.8.10.1. All the paths have been setup. $ python dial_tone.py Traceback (most recent call last): File "dial_tone.py", line 23, in from gnuradio import gr ImportError: No module named gnuradio Any help would be greatly apprecicated. You are a little short with your information: How did you install? I suppose you build from source. Which release or version do you use? Which commands did you run exactly? Please read http://gnuradio.org/trac/wiki/ReportingErrors Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gnuradio and python 2.6 - Debian and Ubuntu
Firas Abbas schrieb on 2009-07-13 05:47: Hi, --- On Mon, 7/13/09, Eric Blossom wrote: GNU Radio works with 2.5 and 2.6 (and most of it works with 2.3 and 2.4 too) The Current GNURadio Binary packages cannot installed on Ubuntu 8.04 because for some reason (may be Johnathan know) it needs python 2.6 which is not available for Ubuntu below 9.04. Same with Debian unstable of today. I managed to install all GNU Radio packages from gnuradio.org/ubuntu/dists/3.1 except gr-comdedi - the comedi libraries were removed -, so the gnuradio-python gnuradio packages are broken. 3.2 is completely uninstallable due to the dependency on python2.6. python2.6 is mayby not getting into the next release, so it would be a pitty if the packages would not be installable with python2.5. Any chance to revert this dependency to >=2.5? Any chance to get the packages into Debian unstable and thus Ubuntu? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Installation problem CentOS ... FFTW3F
Mir M. Ali wrote am 2009-08-13 07:28: The output of pkg-config is shown below and it shows that fftw is installed. $ pkg-config --list-all | grep fft fftw3FFTW - fast Fourier transform library Gnuradio's configure doesn't seem to find it. What can I do now? Please post the corresponding output of configure and the correpsonding lines of configure.log. Maybe we can find the error with more information. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP with USB/IP
Firas Abbas schrieb on 2009-06-05 21:14: Hi, --- On Fri, 6/5/09, Patrick Strasser wrote: Hello! ednet[1] and RaidSonic[2] sell boxes that can forward USB ports over via the Linux USB/IP[3] system. Patrick From the web site the transfer rate of these boxes is 10/100Mb/s. So theoretically it should transfer a maximum of 12.5MByte/sec which is far below the required 32Mbyte/sec of USRP1. 2 Points: 1) USRP is known to be able to transfer maximum 32 MByte/sec, but you do not need to run at this data rate. 2) USB/IP is not limited to this boxes. You can forward USB connections from a Linux box to any other Linux box. The mentioned boxes just happen to do this as their main task. You could do USB over IP forwarding via Gigabit Ethernet, that would give you about 100MByte raw transfer rate, which should be sufficient for maximum USRP data rates. Just wanted to know if anyone used something like this already. I could get hold of one Raidsonic part, maybe I'll give it a try. I'm not shure if USB/IP supports the transfer modes that the USRP uses. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP with USB/IP
Hello! ednet[1] and RaidSonic[2] sell boxes that can forward USB ports over via the Linux USB/IP[3] system. One can also setup a Linux box as the USB server to connect an USB device physicaly whith it and forward the USB connection to another computer. These boxes are small/cheap and supposable maintainance-free, though. Anyone already used USB/IP with USRP? Anyone used one of these boxes with USRP? Patrick [1] http://www.ednet-gmbh.de/?lang=en&page=1&cat=10,70,0&artnr=87025 [2] http://www.raidsonic.de/en/pages/products/external_cases.php?we_objectID=5376 [3] http://usbip.sourceforge.net/ -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Release Notes for 3.2?
Hello!
I tried to get an overview about the changes from 3.1 to 3.2, but it
seems there is no Release Notes or Changes document.
I found Release3.{0,1,2}Branch in the Wiki[1], but these list only the
minor changes in the dot-dot-releases. In the Tarball I only found a
NEWS file which just points to the Wiki.
Is there anywhere a complete list of major new features/ changes and bug
fixes? I like the style of the Linux 2.6 list of changes at Linux Kernel
Newbies[2], which is assambled during the release cycle.
Patrick
[1] http://gnuradio.org/trac/wiki/Release3.2Branch
[2] http://kernelnewbies.org/Linux26Changes
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser
Student of Telematik, Techn. University Graz, Austria
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Where is GR installed in Ubuntu?
William L. Bahn wrote am 2009-05-07 09:21: $ sudo apt-get install gnuradio usrp > > But where did it get installed? I can't find it anywhere. If you have apt-get, you have dpkg too. dpkg -L gnuradio Patrick ps: Always repeat information from the subject in the body. This makes reading, replying and quoting much easier. -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Framework Texte Anpassbarkeit ändern
Patrick Strasser wrote am 2009-04-29 11:12: Sorry, wrong list... Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Framework Texte Anpassbarkeit ändern
Hallo Dorian! Das war eine Sache von 2 Minuten ;-) Danke! -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP2 benchmark_rx.py, benchmark_tx.py, transmit_path_usrp2.py, receive_path_usrp2.py, pick_bitrate.py
Hello! Smith L. wrote am 2009-04-14 22:48: I am using the svn version of GNU Radio. I dont know the revision number. svn info Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: installation of GNU Radio on windows using minGW and MSYS
Zainab Qureshi wrote am 2009-04-28 19:14: I have installed gnuradio on windows xp using the steps given on the gnuradio wesbite. Those were quite helpful. I am getting this when i configure gnuradio. Please read http://gnuradio.org/trac/wiki/ReportingErrors Especially read Things to try before asking questions on the mailing list and I've done everything above, and I still have a question. How do I ask it? Read the output of your commands carefully. The build tools give you a minimum of information to solve your problems. And please do not post HTML-mail. Readers without HTML will not see any yellow words you are referring to. I do not want to send you away, but the things you are asking are no problems that require special GNU Radio knowledge or can not be be solved by reading the docs from the wiki. We expect you to do you homework before asking questions. @others: Are the docs missing some crucial information or somehow misleading? It seems they can be improved, as still people are asking help for quite basic things. Maybe it's just the ordering and structure of some docs or outputs... Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: No module named gnuradio
Jay Kumar wrote am 2009-03-31 09:08: Hello, I have recently installed gnuradio-3.1.3 on Red Hat Enterprise Linux 4.I can even [...] For better readability, please consider following rules: * never a space before punctuation (,;:.!?). * always a space after punctuation. * For better readability it is common, but not compulsory, to add a second space after sentences. See this sentence as example. But only after full stops (.). Patrick ps: Would have sent this as private mail, but could not find one... -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: No module named gnuradio
Jay Kumar wrote am 2009-03-31 09:08: Hello, I have recently installed gnuradio-3.1.3 on Red Hat Enterprise Linux 4. Did you install via the package management system or did you compile yourself? Please provide the sommand sequence you used. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: uses gr.file_sink 32 bit or 64 bit
Markus Feldmann wrote am 2009-03-30 17:54: > You are right, thats also what i am thinking, but to these samples through a fft, i have to know what is a sample ! Thats the topic of this post. Thats what i not understand. What is a sample ? For example, is this ONE sample ? 24 + 5i Yes. The left is a 32bit I part and the right is the Q part ? Yes! The I(nphase)-part is the real component of the complex number, the Q(uadrature)-part is the imaginary component of the complex number If i need more than one line for one sample, how many lines do i need for the fft ? One "line" in your output is one complex sample. You really should read up about complex numbers and FFT, as Brian mentioned. Please do your homework before asking questions. If you do not understand how complex numbers work, you will not find too much people here teaching you such things. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: uses gr.file_sink 32 bit or 64 bit
feldmaus wrote am 2009-03-27 20:52: Further on my graphic does not look like my spectrum in the FFT-sink. A FFT sink displays the frequency domain, it's amplitude versus frequency. Printing the samples shows the time domain, amplitude versus time. The FFT sink feeds the samples through a FFT-block, resulting in its name. A scope sink just plots the samples, as you try with Matlab/Octave. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problem in Installing gnuradio-3.2
Somya Ajmera wrote am 2009-03-15 00:54: Hi , I am facing a problem in installing gnuradio-3.2. I was able to install gnuradio-3.1.3 properly but when I tried to install this newer version on the top of the older version, maximum of the packages are not getting configured including gnuradio-core and usrp. You should always a make uninstall before installing a newer version. Otherwise parts of the old installation may interfere with the new parts. Components of different versions can not be expected to work together. I am attaching the log ./configure file for the reference (open it with word pad). I am a newbie to Linux and to gnuradio. I would really appreciate if anybody can help me regarding this matter. Please tell us more about your setting. Refer to http://gnuradio.org/trac/wiki/ReportingErrors#WhatIfIstillHaveaProblem Your configure output shows: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gnuradio-core usrp gr-usrp gr-usrp2 gr-gcell gr-msdd6000 gr-audio-alsa gr-audio-jack gr-audio-oss gr-audio-osx gr-audio-portaudio gr-audio-windows gr-atsc gr-comedi gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc You won't get any far without a least gnuradio-core, gr-wxgui and gr-utils, and gr-usrp if you want to use the USRP. You won't get any soundcard usage without one of gr-audio-alsa, gr-audio-jack, gr-audio-oss or gr-audio-portaudio on Linux, preferably gr-audio-alsa. You won't have the helpful examples without gnuradio-examples. Did you disable some of them in the configure command line? How did you configure? The output is only a very limited help without the command line generating it. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: A question about the program gr_fir_ccf_generic.cc
Mir Ali wrote am 2009-03-08 09:50: Can someone tell me how line 28 of code gr_fir_ccf_generic.cc works. line 28#if (2 == 4) According to me this condition will always fail isn't it? Yes. This is a convenient way to disable something permanently without removing the code. Maybe the author needs it for debugging or wants to keep it for later. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: usrp alternat
islam saber wrote am 2009-02-25 15:17: i buy fpga kit ( EZ1CUSB-12) and i want to know if i can make by this kit with daughterboard the usrp or not . if not please tell me alternative design for usrp This board seems to be a minimal development board, really some very minimal and basic peripherials. The vendor claims it is good for DSP, but to get in to the level of an USRP you would need at least some highspeed ADCs/DACs. Without them you will not be able to receive or connect any RF signal, what is the purpose of an USRP primarily. If you're looking for some cheaper hardware to do SDR and want to do some fancy soldering yourself, have a look at the SSRP: http://oscar.dcarr.org/ssrp/index.php If you really want to play in the USRP-leage you will have to spend some money, though. Maybe you want to read up on all this with some of the links from http://gnuradio.org/trac/wiki/SuggestedReading There should be enough for some evenings of reading, for starters and for experts ;-) Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Overrun when there shouldn't be
Eric Blossom wrote am 2009-02-10 22:13: Be sure that you're in the usrp group, and that /etc/security/limits.conf contains this line: @usrp - rtprio 50 If you edit /etc/security/limits.conf I'm pretty sure you need to reboot to get it to take effect. You do not need need reboot[1]. Debian man page says: Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session. A new login should do. This can mean loging in and out once, or just saying su $USER will give you the new setting, but only in this session. Patrick [1] This is not Microsoft ;-) -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problem iinstalling fftw-3.2 on Centos 5.2 64 bits
anne kwong wrote am 2009-02-09 13:16: I am getting another problem when running ./configure FFTW3F is compiled with ./configure --prefix=/opt/freeswitch --enable-core-odbc-support --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw Here is my export output declare -x FFTW3F_CFLAGS="/usr/local/include" declare -x FFTW3F_LIBS="/usr/local/lib" Obviously your fftw3f is installed in opt/freeswitch. declare -x FFTW3F_CFLAGS="/usr/local/include" won't do the job in this case... Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Guide for Reporting Errors and Asking for Help
Hello! I wrote some lines for people asking for help in the wiki [1]. For the old stagers, please look through it, it can certainly need some polishing. Especially the common-mistakes section could need some more examples. Patrick [1] http://gnuradio.org/trac/wiki/ReportingErrors -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problem to listen to FM
jingx kwan wrote am 2009-02-22 20:19: Hello, It isn't create any sound from the usrp_wfm_rcv.py command when I set to listen to the Frequency 91.5. It is running under Ubuntus 8.04 and Dell Latitude D610 notebook. I doubt that the notebook sound card doesn't support the below command line. I don't know why I can't listen to the FM. > Could you please point me to the solution? Yes, if you provide a little more information: Have you read all the READMEs, FAQs and things labeled with "doc" or "documentation"? Have searched the mailing list archives? I recommend GMANE.org. Have searched the Internet? If you'r unsure what to do first and what to write in a mail asking for help, have a look at http://www.catb.org/~esr/faqs/smart-questions.html You've told us about your computer model and your OS version, but not about your GNU Radio version. Did you install it through your OS' packet managment system or build from source viw SVN? Which version? Have you tried other commands? Did they work? Some output on the command line? Have you been able to get some sound output with the programs from gnuradio-examples/python/audio directory? If dial_tone.py is not working, you should sort this out at first. I run the following command: ./usrp_wfm_rcv.py -f 91.5M -O plughw:0,0 "It isn't create any sound" is not very specific. Please send us the copy of the output of the command. If there are errors, you have not showed us any trace of it. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: CGRAN downtime
George Nychis wrote am 2009-02-09 18:21: Hi all, CGRAN will likely be down for several hours today while we work on assigning it its own IP address and updating its SSL certificate. Seems you are using a self-signed certificate, which is a no-op in security sense. Have you thought about a CACert cerfificate? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: generate 0s and 1s
yufeng wang wrote am 2009-02-13 14:34: Hi, all, Can anyone tell me which function in Python could I use to generate a fixed length of 0s and 1s? I know in matlab we could just use randsrc(x, y, 0:1), while I've no idea how to implement it in Python. Thanks for ur help! If you want to have random sources in GNU Radio, you can use various sources, like a noise source or a LSFR source[2]. One method for a fixed length: import random length = 10 rand_sequence = random.sample(length/2*[1]+length/2*[0],length) This first generates a list of 1s and 0s and permutates them. You can vary the length/2-part to get a not-even-distribution. Or: rand_sequence = [x%2 for x in random.sample(xrange(1000), length)] These may not be the most efficient or random one, but it should do for a first shot. For really long sequences yu should construct a sequence from a random source with multiple invocations, like multiple random.choice([0,1]) if you need reproducible numbers, or random.SystemRandom([0,1]) to get good non-reproducible numbers. Read all about random numbers and Python in [0] If you are unfamiliar with Python, just read the Python Tutorial[1], it's really great. Patrick [0] http://docs.python.org/library/random.html [1] http://docs.python.org/tutorial/ [2] http://www.gnuradio.org/doc/doxygen/group__source.html -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: attribute error DTD
feldmaus wrote am 2009-02-04 14:38: feldmaus gmx.de> writes: AttributeError: 'module' object has no attribute 'DTD' There seems to be a Problem with this Fie . The attribute doesn't exist. Which version of source and tools are you using? Do you have an stable release or are you using a version from the CVS repository? What system do you compile on? Are you sure that all your Python modules are up to date? Have you checked all READMEs and the mail archives? What did your favorite web search engine answer to your questions? What did you do to solve the problem on your own? Give good and comprehensive information and do your homework, and you'll get good and comprehensive help. If not sure, have a look at "How To Ask Questions The Smart Way"[1] Patrick [1] http://www.catb.org/~esr/faqs/smart-questions.html -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Again on "cannot import name bbn"
Chiara De Dominicis wrote am 2008-12-09 11:53: Hi George! When I run ./bootstrap I get this: doc/Makefile.am:77: `%'-style pattern rules are a GNU make extension doc/Makefile.am:80: `%'-style pattern rules are a GNU make extension Seems the wrong version of something like automake. Have you checked that all your _used_ auto-tools are at the same or higher version as specified in the README file? Often systems have more than one version of say automake installed, and you can configure via a distribution-specific tool which one to use or you can use environment variable to select the right one. If unsure, send us the output of 'automake --version'. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Help! ImportError: cannot import name usrp
Joreen Tan wrote am 2008-10-28 18:36: >>Joreen Tan wrote am 2008-10-28 08:04: >>> The error reported is as shown: >>> Traceback (most recent call last): >>> File "usrp_fft.oy, line 24, in >>> from gnuradio import usrp >>> ImportError: cannot import name usrp >> >> Need more Info: >> Did you compile by yourself or did you use distribution packages? >> What exactly did you do do install GNU Radio? >> What was the exact command line you entered to start the program? > I downloaded gnuradio-3.1.3, i don't really get what u mean by compile > by myself or using distribution package. For some systems, you can install GNU Radio via the package management systems. On ohters you have to get the sourcecode and compile it by yourself. > i did > ./configure > make > make check > sudo make install > > following exactly the same steps that was illustrated in the build > guide. Which build guide did you follow? > didn't know where went wrong but gr-utils, usrp and gr-usrp was > not configured during the ./configure command. Have you checked the output of ./configure? Usually failed checks give a good hint what went wrong. Did you read the README? Did you go through the instructions at http://gnuradio.org/trac/wiki/FedoraInstall? > Please guide me. Thank you so much! Please help us help you. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Help! ImportError: cannot import name usrp
Joreen Tan wrote am 2008-10-28 08:04: > Hi, > > Just started on this project again and faced with this problem with the > gnuradio-3.1.3 version using fedora 9. The error message occured when i > was running gr-utils/src/python/usrp_fft.py > > I am logging in as root. > > The error reported is as shown: > Traceback (most recent call last): > File "usrp_fft.oy, line 24, in > from gnuradio import usrp > ImportError: cannot import name usrp > > Your help is much appreciated. =) Need more Info: Did you compile by yourself or did you use distribution packages? What exactly did you do do install GNU Radio? What was the exact command line you entered to start the program? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP connected during gnuradio installation
Joreen Tan wrote am 2008-10-16 12:27: > Hi, > > Would like to check, if the USRP is needed to be connected to the laptop > during the installation of gnuradio on fedora 9? No, like you don't need a USB stick to install a USB storage driver. GNU Radio does not necessarily need an USRP, although it has lot of code written especially for the USRP. In fact you don't even need a RF interface to do signal processing, and you can use a lots of different hardware for input and output, including your soundcard and hardware supported by Comedi[1] Patrick [1] http://www.comedi.org/ -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: gnuradio .deb won't install on ubuntu intrepid
Dimitris Symeonidis wrote am 2008-10-08 17:49: adding the repository to the 3rd party sources and running "sudo aptitude install gnuradio usrp" gives me: The following packages have unmet dependencies: python-gnuradio-comedi: Depends: libcomedi-0.7.22 which is a virtual package. this is because python-gnuradio DEPENDS on python-gnuradio-comedi can we turn this dependency into a "recommends"? Had the same problem with Debian testing some days ago. As a workaround you can deselect python-gnuradio but select all its dependencies excluding comedi. Of course this will leave the package gnuradio with unfulfilled dependencies, but you can do it the same way with this package. Python-gnunradio depends on a lot of things, which should be all recommends IMO, especialy as a dependency of gnuradio. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Radio beginner
Patrick Strasser wrote am 2008-09-23 15:23: [...] and to read the Python Tutorial[1] That is: [1] http://docs.python.org/tut/ Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Radio beginner
Mohd adib Sarijari wrote am 2008-09-23 13:04: hi, i am very new with GNU Radio. now i am in process of installing the GNU Radio but unfotunetly i still fail to install.. i had try for 3 days. i follow the GNU Radio installation Note by Naveen Manicka. Please help us to help you with more information: * Which system/OS are you using? * If you use a guide from the Internet, please give us a URL so we can compare. i had finished step one (installing the gnuradio-core). now when i want to install gnuradio-example it tell me to set the phyton path environment variable. What exactly was the output? i had run the command that it give in the installation note.. ($ export PYTHONPATH=/usr/local/lib/python2.4/site-packages) but when i type $phyton it dose not give feed back as in the note (>>> from gnuradio import gr) The $ is the prompt, that shows you that you can enter commands. The _following_ words are the commands to the shell. You must not enter the $. The programs name is python, so you should enter only the name. It is common to write commands with the $ in front to hint you to a shell command. Sometimes it's not $ but #, which means you should not enter the commands as normal user as $ hints, but as root, the super user. can any one help me? i am very sorry to post this very basic issue but i am totally new in GNU Radio and i think i am the first to try GNU Radio in my country. currently i am doing my master by Research. Seems you are not familiar with Unix/Linux. I'd recommend you to read a beginners guide to Linux, and to read the Python Tutorial[1] thank you in advance. You're welcome. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Can we control the rate at which a block spews data
Murtuza wrote am 2008-09-09 11:01: This gold code block generates PN seq at a rate that is depended upon the computer's performance ability. If I want to send a controlled sequence at 2Mcps how do I do this ? Use gr.throttle after your block. GNU Radio blocks are free running and only constrained by the speed of sources, speed of sinks, machine performance and gr.throttle. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Decimation rate
Eric Blossom wrote am 2008-09-04 05:23: On Thu, Sep 04, 2008 at 12:56:13AM +, WeiXiaowei wrote: Does anyone know whether it is possible to set demication rate to be 2 to double the bandwidth when running usrp_rx_cfile.py to record the incoming signal? No, decimation of 2 does not work with the standard fpga image. With sufficient effort, it's probably possible to get 4-bit I & Q working, which could allow 32MHz bandwidth. The limiting factor is USB bandwidth. USB hast 480 Megabit/sec gross data rate, which translates to a effective maximum of 32 Megabyte/sec to transfer between the host and the USRP. The USRP samples at a rate of 64 Msamples/sec with 12 bit/sample complex, which are sent as 2x16 bit/sample = 4 bytes/sample. (32 Mbyte/sec)/(4 byte/sample)=8 Msamples/sec. This is exactly what a decimation factor of 8 yields. With 8 bit/sample real, that is 16 bit/sec complex, you can double you sampling rate, but loose 4 bit of resolution. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: One simple question
Murtuza wrote am 2008-08-12 05:47: hi friends, Can anyone tell me how one can implement a block that generates a sequence of bits at a rate of 2Mbps. Have you had a look at the docu? Look at http://www.gnuradio.org/trac/ and especially at http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html Blocks in GNU Radio generally do not have a instrinsic speed but are constrained by the rate of their sources and sinks and of course by the speed of your machine. In a software-only (no USRP or Audio) applications you'd likely use gr.throttle. I am new to Gnuradio and working towards implementing a sequence generator on gnuradio. I did not find any block which already does this (atleast this is what i believe is true). Please be more specific in what you want to implement. Do you want to have very special sequences, or repeat sequences, or PRN? What do you need it for? GNU Radio has a vector source, and you can load it with arbitrary values. You could also use a file as source and generate you data outside GNU Radio. Of course the file can be a pipe and you could use another program to generate your sequence on the fly. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: usrp_wfm_rcv.py failed to set initial frequency error
Halil Yigit wrote am 2008-08-08 16:33: [W]hen I test usrp_wfm_rcv.py -f 2400M there is no error message 'failed to set initial frequency' but other warnings are still there: 1. FYI: No powermate or Contour Knob This is just an information. If you have one of the two mentioned input devices, you can use them to control the interface, e.g. set the frequency, volume etc. 2. (python 6931): GnomePrintCupsPlugin-WARNING **: The CPUS printer couldnt be created A known message from GNOME. You should not worry, you can ignore both. In the range of the RFX2440 you won't find any FM radio, so you will just get static noise. Not very interesting. Use a BasicRX or a TVRX for FM Radio, these support 88-108MHz. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Basic RX. - usrp_wfm_rcv.py
rita pfc wrote am 2008-07-30 19:30: OK Patrick I'll take into account next time. At the end I could solve my problems. Now I'm trying to transmit with the Basic TX Good to hear it's working! What was wrong, just for the records? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Basic RX. - usrp_wfm_rcv.py
Brian Padalino wrote am 2008-07-29 17:07: On Tue, Jul 29, 2008 at 11:01 AM, rita pfc <[EMAIL PROTECTED]> wrote: Hello, I've started again from the begining. I have installed Ubuntu 7.1, not in a virtual machine. In a Pentium IV, 3 GHz, with 2 GBytes of RAM. Much better, we do not support VMware. SystemError: wxEntryStart failed, unable to initialize wxWidgets! (Is DISPLAY set properly?) Fallo de segmentación (core dumped) I hate to just repeat the error, but is DISPLAY set properly? Did you use sudo? sudo sometimes has problems to get the X settings like DISPLAY and authority right. If you are not really know what certain commands do, quote it in your messages. Even subtle or innocent looking things can be important for your problem, so tell us as much and as exact as possible what you did. Otherwise we are not able to reproduce the problem and find the missing or wrong part. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Basic RX. - usrp_wfm_rcv.py
Rita's pfc wrote am 2008-07-28 19:03: Thank you for the answer. I did what you told me about "-f 100M", but it happened the same. I tried to do with usrp_wfm_rcv_nogui.py and it happened the same. About the antenna, I supposed that just a simple peace of metal hooked on the daughterboard would be enough. Should I buy a specific antenna for any frequency in FM band that I wanted to listen with the Basic RX? Maybe it's a stupid question. No Stupid Question. Yes, a FM antenna should do, but you have to look for an adaptor, could be tricky. Your screenshot just hides the relevant information from the console, but moreover it's more useful to have a text copy of what's going on on your terminal. Seems like the application is kind of hung. Tell us more about your setup: OS? Distribution? Version? Version of GNU Radio you are using? Hardware: RAM, CPU? Open a system monitor before starting the application and watch memory and CPU consumptions. I can hardly listen to FM with my PII 450MHz. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Basic RX. - usrp_wfm_rcv.py
Rita's pfc wrote am 2008-07-25 17:39: First of all, I've run the dial_tone.py example, and it was ok. Then, I wanted to use the USRP, so the next example I wanted to test was the usrp_wfm_rcv.py. I've connected a Basic Rx daughterboard to RXB. I write ./usrp_wfm_rcv.py -f 100, I get an error message: FYI: No powermate or Contour Knob found; http://www.nabble.com/file/p18654189/error_fm.jpg This is more an information message than error. The Powermate and the Contour knob, if present, are used for more convenient usage, but the program still runs without any of them. You can use the interface with the mouse without a drawback. Regarding your problem: The option "-f 100" in your command instructs your program to listen FM at a frequency of 100Hz. The option takes magnitude suffixes, so you'd rather want "-f 100M". Choose a frequency of a strong radio station in your area. You will not be able to listen so FM radio without a adequate antenna. For a dipole the receiving length of your antenna should be in the order of lambda/2, that is c/f/2 = 3*10^8/1*10^8/2=1.5m. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FSK with RFX2400
kaleem ahmad wrote am 2008-07-23 16:23: I have just provided the information which can be helpful for you Seen it, just after I pressed the send button. Race condition ;-) Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FSK with RFX2400
Hello Kaleem!
kaleem ahmad wrote am 2008-07-23 15:58:
If you have two USRP boards and two RFX2400 daughter cards then you can try
these codes (fsk_tx.py and fsk_rx.py) using:
Which version of GNU Radio are you using?
Which cable/antenna setup do you use?
You are hard coding your frequency. You could extend the options to set
the frequency with a parameter to get more flexibility.
Moreover with two USRP you are probably not exactly at the same
frequency. Read
<[EMAIL PROTECTED]> [1]:
8<--
The 64MHz oscillator on the board has a maximum 50PPM error. This
gives an error of up to 3200Hz.
8<--
You can watch the sender (and find the apparent receiver frequency) with
usrp_fft.py (from gr-utils) .
You could try it first with a lower frequency. Start with a Basic{RX,TX}
if you have, this results in less error. If you really need to use
2.6GHz, you will have to find and lock your signal before you will be
able to get good transmissions.
Patrick
[1] http://permalink.gmane.org/gmane.comp.gnu.radio.general/11044
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser
Student of Telematik, Techn. University Graz, Austria
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FSK with RFX2400
kaleem ahmad wrote am 2008-07-23 11:38: Dear All, Can anyone also address the first part of my question aslo, I mean how to improve the quality of received data. I mean is it normal with GNU Radio/USRP that we receive so currupt data or I am doing something wrong. Any suggestion please Before you wrote after using tune to set the proper ferquency I was able to run transmitter and receiver > sussfully. I didnt change anything else in the example. > The problem is data which I receive is too much corrupt (lot of data errors).. Your description is not very exact. You could help us to help you with more information: What is your setup? OS, distribution, used version of packages, GNU Radio, hardware setup, used parts (cable, antennas), environment. What do you do? Which code do you use? What did you change? What did you get? Error messages? (add _exact_ transcripts of errors) What did you expect? Please provide exact information, code should be attached. If you changed something, mark the changes so helpers will find it easier. If you have recorded samples of a good and bad transmissions, send us a representative part of it. If you need to show more than a hand full of kilobytes, put them on a web server or ftp server and provide a link. Are you sure to have read the FAQ and introducing documentation? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
