Re: [Discuss-gnuradio] how to change the channel width when data is transmitting
It works! Thanks a lot for the suggestion, but I think its enabling real time scheduling that helped :). The Tx amplitude did not make any difference. Now I am checking how many of these packets reach successfully to the receiver. On Fri, Dec 5, 2008 at 12:40 AM, Firas Abbas <[EMAIL PROTECTED]>wrote: > Hi, > > I have a strange suggestion to you (it worked for me in some time earlier). > If it works for you please give us a feedback. > > > > the Suggestion: > > Change TX amplitude from 12000 (as you stated in your email) to 2000 and > redo the experiment. > > > Note: > To run with real time scheduling, start your program with sudo (as a root) > > > > > Best regards, > > > Firas > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to change the channel width when data is transmitting
Hi, I have a strange suggestion to you (it worked for me in some time earlier). If it works for you please give us a feedback. the Suggestion: Change TX amplitude from 12000 (as you stated in your email) to 2000 and redo the experiment. Note: To run with real time scheduling, start your program with sudo (as a root) Best regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to change the channel width when data is transmitting
Hi guys,
Thanks a lot for all the help. Continuing where Jing left (we work in the
same team) ...
My installation is on ubuntu 8.10 using the repositories listed on gnuradio
website. I am calling benchmark_tx.py with interpolation of 512 and trying
to change it every alternate packet to 256. Other details:
>>> gr_fir_fff: using SSE
bits per symbol = 1
Gaussian filter bt = 0.35
Using TX d'board A: Flex 2400 Tx MIMO B
Tx amplitude 12000
modulation: gmsk_mod
bitrate: 125kb/s
samples/symbol:2
interp: 512
Tx Frequency:2.5G
Warning: failed to enable realtime scheduling
The added code is the in the while loop:
payload = struct.pack('!H', pktno & 0x) + data
#Ritesh
if pktno % 2 == 0:
tb.stop()
if curr_interp == options.interp:
curr_interp = (options.interp)/2
else:
curr_interp = options.interp
tb.wait()
tb.txpath.u.set_interp_rate(curr_interp)
tb.start()
#time.sleep(0.01)
send_pkt(payload)
Anyways, it looks like if I do not use the wait() call (as suggested by
Firas), then either of the following 4 things happen after some packets are
transmitted. The number of packets that get transmitted before the program
stops is not constant.
---
1. Segmentation fault. The gdb backtrace is here:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4dd2b90 (LWP 20950)]
0xb66be8ea in fusb_devhandle_linux::_cancel_pending_rqsts () from
/usr/lib/libusrp.so.0
(gdb) bt
#0 0xb66be8ea in fusb_devhandle_linux::_cancel_pending_rqsts () from
/usr/lib/libusrp.so.0
#1 0xb66bf595 in fusb_ephandle_linux::stop () from /usr/lib/libusrp.so.0
#2 0xb66b28a5 in usrp_basic_tx::stop () from /usr/lib/libusrp.so.0
#3 0xb66bb70d in usrp_standard_tx::stop () from /usr/lib/libusrp.so.0
#4 0xb6676860 in usrp1_sink_base::stop () from
/usr/lib/python2.5/site-packages/gnuradio/_usrp1.so
#5 0xb7bbdead in gr_single_threaded_scheduler::main_loop () from
/usr/lib/libgnuradio-core.so.0
#6 0xb7bbe83d in gr_single_threaded_scheduler::run () from
/usr/lib/libgnuradio-core.so.0
#7 0xb7bbc414 in gr_scheduler_thread::run_undetached () from
/usr/lib/libgnuradio-core.so.0
#8 0xb79313fd in omni_thread_wrapper () from /usr/lib/libgromnithread.so.0
#9 0xb7eb450f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb7e027ee in clone () from /lib/tls/i686/cmov/libc.so.6
I also sometimes see these statements printed on stdout "fusb: (status -2)
No such file or directory", "fusb::pending_remove: failed to find urb in
pending_rqsts: 0x94f04f0"
2. One time it crashed without segmentation fault. It printed a huge report
which I am attaching in the end of the email.
3. Sometimes it aborts after some failed assertions like:
python: ./gr_buffer.h:96: unsigned int gr_buffer::index_add(unsigned int,
unsigned int): Assertion `s < d_bufsize' failed.
OR
python: /usr/include/boost/shared_ptr.hpp:315: T*
boost::shared_ptr::operator->() const [with T = gr_message]: Assertion
`px != 0' failed.
4. Very few times it goes through fine.
-
If I do put the tb.wait() statement, then the program keeps waiting. And gdb
trace shows it stuck in the wait() call. Here is the gdb backtrace:
#0 0xb7f2f430 in __kernel_vsyscall ()
#1 0xb7ee2bf7 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb795ff0d in omni_thread::join () from /usr/lib/libgromnithread.so.0
#3 0xb7bef75e in gr_top_block_impl::wait () from
/usr/lib/libgnuradio-core.so.0
#4 0xb7beed10 in gr_top_block::wait () from /usr/lib/libgnuradio-core.so.0
#5 0xb7c74bef in top_block_wait_unlocked ()
from
/usr/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
#6 0xb7c7cebd in ?? () from
/usr/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
#7 0x0805d867 in PyObject_Call ()
#8 0x080cd502 in PyEval_EvalFrameEx ()
#9 0x080d0345 in PyEval_EvalCodeEx ()
#10 0x080ce728 in PyEval_EvalFrameEx ()
#11 0x080cfbf5 in PyEval_EvalFrameEx ()
#12 0x080d0345 in PyEval_EvalCodeEx ()
#13 0x080ce728 in PyEval_EvalFrameEx ()
#14 0x080d0345 in PyEval_EvalCodeEx ()
#15 0x080d0557 in PyEval_EvalCode ()
#16 0x080edf8f in PyRun_FileExFlags ()
#17 0x080ee25a in PyRun_SimpleFileExFlags ()
#18 0x080595e7 in Py_Main ()
#19 0x08058962 in main ()
If I do not change the interpolation rate every alternate packet and instead
do it every 4th or 5th packet, then the program seem to go through fine.
Hopefully this info is useful to debug whats going on.
Thanks,
Ritesh
---
The report related to #2 above:
*** glibc detected *** python: double free or corruption (fasttop):
0x09fb4f60 ***
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6[0xb7daa3f4]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7dac456]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7a20031]
/usr/lib/libusrp.so.0(_ZN19fusb_ephandle_
Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio
From: Johnathan Corgan <[EMAIL PROTECTED]> To: Bill Stevenson <[EMAIL PROTECTED]> Cc: discuss-gnuradio@gnu.org Sent: Thursday, December 4, 2008 6:25:24 PM Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio On Thu, Dec 4, 2008 at 1:04 PM, Bill Stevenson <[EMAIL PROTECTED]> wrote: > -r 400k -s 1500: 50% of the transmitted packets are received, but 0 right. For comparison purposes, can you try using the GMSK modulation? Just remove the '-m dqpsk' from the command line. -Johnathan Johnathan, I tried gmsk and dbpsk once again, the results of PER are shown below: for gmsk: -r 400k -s 200 nearly 100% right -r 400k -s 500 nearly 98% right -r 400k -s 1500 nearly 97% right for dbpsk: all of the cases gave almost 0% PER, which means communication were very good! Johnathan, could you tell me the detailed configurations of your setup, for example, which demo files were you using, what were the arguments you used for your transmission? I also hope the data I got is useful for your development. Thank you!!! Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple QPSK baseband transmission using GRC
On Thu, Dec 4, 2008 at 12:11 PM, Jérémy Skelton <[EMAIL PROTECTED]> wrote: > To problem is that I'm not able to recover the original data but only the > repetitions of it : I repeat several times two bytes in the input file and I > get several two other bytes at the output. It looks like you have the endianess wrong. The DBPSK modulator works MSB to LSB on the incoming bytes, while your demodulator is packing the bits back into bytes LSB to MSB. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MAC physical interface GNU Radio.
Hello all, I am kind of new to gnu radio. I want to implement a CSMA/CA type MAC protocols on the radio. I have some basic questions regarding the implementation. 1) How easy is to implement a packet based CSMA/CA on the gnu radio? Is there any existing code that is public? 2) Reading all the mailing lists, I have seen that most people implement the CSMA type MAC protocols in Click modular router and then interface it to the gnuradio (UT Austin fellows have done this). How easy is this interface? Is it straight forward? Can some one point me to such an existing interface? 3) What do you recommend? In our experiments the physical layer will be controlled by the mac and we would also want constant control information from the physical layer. a) Gnuradio (CSMA+PHY) b) Gnuradio (PHY) + Click modular router (CSMA/routing). 4) I have read in some posts about the inband-signaling code. Where can I find more information about what it is? Will this solve the problems I have mentioned above without using click. Thanks a lot in anticipation -RadhaKrishna Ganti ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio
On Thu, Dec 4, 2008 at 1:04 PM, Bill Stevenson <[EMAIL PROTECTED]> wrote: > -r 400k -s 1500: 50% of the transmitted packets are received, but 0 right. For comparison purposes, can you try using the GMSK modulation? Just remove the '-m dqpsk' from the command line. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DTMF, AFSK1200 gnuradio block
On Thu, 2008-12-04 at 17:07 -0500, [EMAIL PROTECTED] wrote: > I am considering if I should create gnuradio blocks to detect DTMF, > AFSK, and other digital transmission modes that I currently detect > using multimon (http://www.baycom.org/~tom/ham/linux/multimon.html). > I have no USRP yet. I just use the audio from a VHF/UHF amateur radio > attached to my PC sound card. This is fine. GNU Radio blocks that work on audio rate input from sound cards don't need changing to work with audio rate data produced from the output of demodulators or other blocks that ultimately get their data from something like the USRP. > Since I'm new to gnuradio, I'd appreciate anyone's ideas on what > should be the inputs and outputs of these gnuradio blocks. Also, > does anyone think these blocks might be useful sometime to someone > other than myself? Regarding DTMF detection, there already exists a tone-detection utility that uses the Goertzel DFT optimization to detect the presence of a particular frequency in the data. You could use eight instances of this with appropriate combinatorial logic to output DTMF detection events. (Actually, I think that is what multimon itself does, if I recall correctly.) But it depends on how you want to use these detection events. Traditional GNU Radio flowgraphs terminate in some sort of data sink that communicates with the outside world. If you're simply trying to replicate a multimon type text output, you can "printf" from your detection block. If you want to interact with something non-GNU Radio, like a GUI or some other logic, you need to consider how to signal the start and stop of a detection event to this external code (see below). > I have years of professional experience developing softare in C and C++ > as part of large projects, but I have no gnuradio experience (yet), except > for writing a simple example gnuradio application in Python and writing > a simple example gnuradio block in C++. This is a great start. > Do these DTMF and AFSK detector blocks seem like they should be gnuradio > 'mblocks' instead of gr-blocks? This is one of those cases we have not done very well in addressing, where the input data comes from the continuous data flow domain of an audio card input source or the output of an RF demodulator, yet the output needs to be a set of discrete events that interacts with the outside world. Traditionally, the way we have handled this has been to convert the events into some stream of data as a block output, then wire this to a special I/O block called a message sink. The message sink maintains a FIFO of fixed size items which have a thread-safe query mechanism to retrieve items posted to the queue. It works, but is somewhat crude. Code outside the GNU Radio flowgraph can make blocking or non-blocking calls to retrieve items and generate events in some other domain. For example, we use this mechanism in the graphical FFT displays. The FFT vectors are created by the GNU Radio flowgraph, but the flowgraph itself terminates in a message sink. A separate thread, created in Python and not part of the GNU Radio flowgraph, queries the message queue and posts wxPython window events to the display as the vectors come in to the message sink and get added to the queue. The gr-pager application works similarly, in that the flowgraph does the FLEX pager decoding and generates a stream of decoded pages as vectors and sends these to a message sink. A separate thread queries the message sink and displays the pages to the screen sequentially. So to your original question, the short-term answer is that you should implement a C++ block in traditional gr-block format that outputs DTMF digits sequentially. Wire it to a message sink in your flowgraph and you can write code outside GNU Radio proper to query the queue and do whatever you want with them. The mblock library was supposed to be a way to address this, as it works entirely in the message passing domain, yet as I stated in an earlier email, the bridge between the streaming domain and mblock domain has never been implemented in an acceptable way. We are now looking at adding event passing to the traditional gr-block world such that blocks can be written that accept and produce either message events or streaming data. In that case you'd write a block that would take in streaming audio data and generate DTMF symbol detection events. Regarding AFSK, that is clearly a streaming block that would convert audio samples into bits at a fixed input to output sample ratio. The audio input would either come from a soundcard input source or from a narrowband FM demodulator block (which already exists.) You'd probably then write another block that does the deframing on the input bits and generates a series of payload packets and ultimately sends these to a message sink. This is similar to gr-pager that uses an MFSK demodulator to get to bits and then a deframing sink that outputs individual pages. -Johnathan
Re: [Discuss-gnuradio] DTMF, AFSK1200 gnuradio block
Hello all: I am considering if I should create gnuradio blocks to detect DTMF, AFSK, and other digital transmission modes that I currently detect using multimon (http://www.baycom.org/~tom/ham/linux/multimon.html). I have no USRP yet. I just use the audio from a VHF/UHF amateur radio attached to my PC sound card. Since I'm new to gnuradio, I'd appreciate anyone's ideas on what should be the inputs and outputs of these gnuradio blocks. Also, does anyone think these blocks might be useful sometime to someone other than myself? I have years of professional experience developing softare in C and C++ as part of large projects, but I have no gnuradio experience (yet), except for writing a simple example gnuradio application in Python and writing a simple example gnuradio block in C++. Do these DTMF and AFSK detector blocks seem like they should be gnuradio 'mblocks' instead of gr-blocks? I know little about mblocks. Can anyone direct me to mblock documentation? The doxygen generated documentation I've found so far seems better suited as a reference for someone who already knows gnuradio rather than someone new to gnuradio. Griff -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/discuss-gnuradio@gnu.org/10888126.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] testing outside building with our USRPs
From: David Burgess <[EMAIL PROTECTED]> To: Daniel O'Connor <[EMAIL PROTECTED]> Cc: Bill Stevenson <[EMAIL PROTECTED]> Sent: Tuesday, December 2, 2008 1:27:07 AM Subject: Re: [Discuss-gnuradio] testing outside building with our USRPs Thank you, David and Daniel! I found a very handy power system that could be easily used for outside testing. It might be useful for other Gnuradio fans who want to test for free space comm. http://www.batteriesareus.com/index.php?main_page=product_info&cPath=139_25&products_id=113 Bill True. The brute force approach is to get a few big-a RV batteries and an inverter. We got a good deal on a 400 W inverter a couple of months ago, $30 for a 400 W unit at Home Depot. The inverter draws at least 10 W just sitting idle, so you'll take a hit on efficiency, but that might not matter for your application. Put it all on a cart and roll it back to the lab/shop/whatever every evening for recharging. -- David On Dec 1, 2008, at 8:37 PM, Daniel O'Connor wrote: > On Tuesday 02 December 2008 13:23:49 Bill Stevenson wrote: >> Thank you for your information about the laptop power rig. But our problem >> is we have to use eight USRPs as our nodes in our experimentation, and we >> do not have so many laptops, so do you know how to get 110-220 voltage >> input for our computers when testing outside? Thank you! > > You could parallel up a few car batteries and run the PCs off an inverter. > > The power requirements are variable depending on your PCs of course :) > > --Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C David A. Burgess Kestrel Signal Processing, Inc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio
From: Johnathan Corgan <[EMAIL PROTECTED]> To: Bill Stevenson <[EMAIL PROTECTED]> Cc: discuss-gnuradio@gnu.org Sent: Wednesday, December 3, 2008 2:57:55 PM Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio Thank you, Johnathan! I did my experimentation again with different configuration. Below are the arguments I used for my experimentation: -r 400k -s 1500: 50% of the transmitted packets are received, but 0 right. The received packet number increased continuously. -r 400k -s 500: 66% of the transmitted packets are received, but 0 right. The received packet number increased continuously. -r 400k -s 300: 71% of the transmitted packets are received, but 0 right. The received packet number increased continuously. -r 400k -s 200: 93.6% of the transmitted packets are received, but 0 right. The received packet number increased irregularly. One USRP is controlled by my laptop (Compaq Presario C700, 1.46GHz Dual-Core Pentium, 1GB RAM), which is used for Tx and another USRP is handled by a desktop (Gateway, 2.40GHz, Core 2 Dual, 2GB RAM), which is used for Rx. The two USRP are 3m apart from each other. The reason why we used 2Mbps for dqpsk case was that when the bit rate is up to 2Mbps, the PER ratio could somehow reach its 'minimum value', and there is no uO sign on my desktop PC, but there was one or two uU signs on my laptop part when s is set to 100. I really cannot figure out why I cannot get dqpsk scheme done when you have successfully verified it works fine in your configuration. I am totally confused, is there anything wrong with my setup described above, Johnathan? I really need guidance. Thank you!!! Bill On Mon, Dec 1, 2008 at 1:07 PM, Bill Stevenson <[EMAIL PROTECTED]> wrote: > python benchmark_tx.py -f 2479M -r 2000k -m dqpsk -s 100 (-s 800 or -s 1500) > python benchmark_rx.py -f 2479M -r 2000k -m dqpsk What is the CPU type and speed you are using? In my experience, data rates above about 500 kbps are difficult to receive on a typical laptop platform due to lack of sufficient CPU cycles. On an Intel Core2 Duo at 2.1 GHz (IBM Thinkpad T60), I can't go above 800 kbps. Your rate of 2 Mbps is likely much too high. Are you seeing any "uO" on your output? -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simple QPSK baseband transmission using GRC
Hi, I have been trying to make a baseband transmission by assembling blocks with GRC. I'm using this scheme : http://www.skelton.eu.org/Image1.png To problem is that I'm not able to recover the original data but only the repetitions of it : I repeat several times two bytes in the input file and I get several two other bytes at the output. Any idea to solve this ? Is it possible that the decoding block takes a bad phase (maybe due to quadrature demodulation)? If so, what block can I use to make the phase correction ? Thanks, Jérémy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Again on "cannot import name bbn"
Chiara De Dominicis wrote: My machine is an OpenSUSE11 and I installed both current GNURadio version and subversion r7596. Do I forget something? Hi Chiara, I have only tried installing it on Ubuntu. I wrote the instructions on CGRAN and it worked fine for me. Are you making sure you get no errors trying to make or make install on it? - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New svn version
On Wed, Dec 3, 2008 at 1:40 AM, Paolo Di Monte <[EMAIL PROTECTED]> wrote: > My distribution is Gentoo Linux. [,,,] > Any help would be very appreciated; just let me know what other informations > could be useful to try to solve the problem > thank you Unfortunately I have not personally worked with the Gentoo "port" of GNU Radio, so I can't really help you here. Hopefully there are others on the mailing list with the relevant experience. From the error messages, it appears that in the build environment, the default search path for include files is missing something that is assumed to be there by the build system (though I'm just speculating here.) -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio roadmap and master thesis
On Wed, Dec 3, 2008 at 1:01 AM, Mikael Johansson <[EMAIL PROTECTED]> wrote: > I am curious about what (and when) to expect from future releases. As is the case with most open source development projects, the feature set tends grow "organically" rather than by strict adherence to any sort of long-term roadmap. This is primarily because most of the software (and documentation) gets written by volunteers and contributed to the project, as distinct from a paid development team working to a schedule and set of release requirements. That isn't to say that Eric and I don't have long term plans or that there isn't a coherent architecture that we have in mind. Indeed, some have argued that we have been too strict in accepting contributions or that we've set the bar too high for developers to push code into the official release tree. The last year has been a period of intense development by a number of individuals and groups that is finally coalescing into a stable 3.2 release. Among much else, the delta between release 3.2 and 3.1 will include: - A switch from a single threaded scheduler to a thread-per-block scheduler capable of scaling with multi-core and multi-processor systems - Support for all C++ applications without the need for Python, including full support for the USRP/USRP2 in this mode - A port to support the Cell Broadband Engine processor - The addition of the GNU Radio Companion, a graphical editor for building and executing GNU Radio flowgraphs - An OFDM modulation and demodulation system suitable for packetized transmission systems - OpenGL acceleration of the graphical display sinks - Initial introduction of USRP2 hardware support All the above has already been available for use as part of the "development trunk" as it gets developed, so in one sense the 3.2 release is really just a coherent snapshot in time that will be maintained with bug fixes and API compatibility through the release series. Also not captured in the above list are the numerous additions to the core set of DSP blocks. There have been a few features that are "on deck" but not quite yet ready; these will likely show up in the 3.2.x official releases: - Formal introduction of the 'mblock' concept. This implements an event-based block system that greatly simplifies working with packetized data in the GNU Radio environment. While the basic mblock library has existed for quite some time, a satisfactory bridge between the continuously streaming gr-block domain and event-driven mblock domain has not been developed, making this overall feature set of limited appeal and use. We have been experimenting with an alternative design that adds event-driven message ports to the existing gr-block design instead. - "In-band" signaling for the USRP1 and USRP2. This supports timed transmission and reception of samples, as an alternative to the streaming mode that exists now. Most of this already exists for USRP1 in the mblock environment, but similarly to the above, is difficult to integrate with existing GNU Radio blocks. The low-level C++ API for the USRP2 hardware already supports timed transmission and reception, but needs the same support in GNU Radio itself. - A full set of C++-only programming examples. The primary thing lacking here is modification to the GNU Radio build system to support more granular component dependency checking. More features are in development, but we tend not to discuss them publicly until we can actually show some working code that people can try for themselves. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Format and dimension of USRP output samples
On Thu, 2008-12-04 at 12:28 -0500, Marco Bottino wrote: > I'm using the USRP Motherboard with a LFRX daughterboard. > Question: if the ADC has 12 bits, each sample that arrives from the > doughterboard is 12 bits real or imaginary. But over the USB the samples (real > or imaginary) are 16 bit signed integer. If my resolution is 12 bits, why do I > need 16 bits? It is correct that the ADC samples at 12-bits per sample. This occurs at 64 Msps. The USRP FPGA contains performs some processing on these samples to reduce the frequency content and sample rate of the stream before sending over the USB. During this processing, the effective number of bits increases to (at least) 16. Even if it weren't so, it would still be simpler and faster to pack 12 bits into 16 bits for transmission over USB. > Moreover, using a program like Baudline, the format of the samples I have to > use > is complex 32 bits floating point. If they are integer, why floating? The GNU Radio block for reading or writing samples to the USRP can use either short integers or 32-bit floating point. The majority of GNU Radio DSP blocks work in floating point, as it simplifies dealing with issues like dynamic range and overflow that would otherwise require more strict design in the fixed point domain. The conversion to and from floating point occurs in the USRP source_c() and sink_c() blocks and is transparent to the user. If you opt to use the short integer sources and sinks (usrp.source_s() and usrp.sink_s()), you may need to write your own low-level DSP blocks for the remainder of the flowgraph to work in this domain. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Format and dimension of USRP output samples
Hello everybody, I'm sorry to post once again a question about the dimension and the format of the samples output by the USRP, but it is actually hard for me to understand. I'm using the USRP Motherboard with a LFRX daughterboard. Question: if the ADC has 12 bits, each sample that arrives from the doughterboard is 12 bits real or imaginary. But over the USB the samples (real or imaginary) are 16 bit signed integer. If my resolution is 12 bits, why do I need 16 bits? Moreover, using a program like Baudline, the format of the samples I have to use is complex 32 bits floating point. If they are integer, why floating? Thank you very much, kind regards, Marco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] warning for transmit data with benchmark_tx.py
On Thu, Dec 4, 2008 at 2:47 AM, Halil Yigit <[EMAIL PROTECTED]> wrote: gr_fir_fff: using SSE > warning : failed to enable realtime scheduling Some GNU Radio applications are written to try to set the process scheduling priority to realtime in order to obtain the best possible performance. However, unless your system is specifically configured to allow your userid to have this privilege, it will fail with the above error message. This is not in itself a problem unless your application needs the extra performance. You will need to consult the documentation for your specific OS to determine how to enable this, or run the application as the root user. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Re: Complex samples format with ASK
Hello, Selon Paul Mathews <[EMAIL PROTECTED]>: > You have to choose reasonable values for the decimations and filter > parameters. The attached file runs without generating compiler errors, but > it's up to you to take it from here. > Paul > If, as you say, it runs, what does "RuntimeError: complex_to_mag(4): insufficient connected output ports (1 needed, 0 connected)" means? Maybe that the output is not used (even if I don't understand why), so for that it stops? thank you Marco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Again on "cannot import name bbn"
Hi list! I tried to install the 802.11 BBN code following exactly the instruction in the https://www.cgran.org/wiki/BBN80211 page but when I run any example I got this error: > Traceback (most recent call last): > File "bbn_80211b_rx.py", line 33, in > from bbn_80211b_pkt import * > File "/home/cmdd/bbn_80211/src/examples/bbn_80211b_pkt.py", line 31, in > > from gnuradio import bbn > ImportError: cannot import name bbn > My machine is an OpenSUSE11 and I installed both current GNURadio version and subversion r7596. Do I forget something? Thanks a lot Chiara ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code for current release (3.1.3)?
Yihu Li wrote: > Hi everyone, > > I am new to gnuradio and plan to do some cross-layer implementation (MAC > and PHY layers with MIMO) on gnuradio. I intalled the newest stable > version of gnuradio (v3.1.3) and plan to use BBN 802.11 code or > span80211b with it. However, it seems that BBN 802.11 and span80211 code > can only be used with the earlier version of gnuradio (see > https://www.cgran.org/wiki/Projects ). I read the emaillist archieve and > found some people were discussing this and working on it. What is the > newest updates about this? Does anyone successful use it this way? > > Thank a lot. > > Yihu > > I've been on and off working on this, and expect to be spending more time on it now. However, I don't currently have anything that works with the latest stable release. I have a branch in the bbn_80211 project (https://www.cgran.org/cgran/projects/bbn_80211/branches/douggeiger) if you want to see what I'm working on at the moment - but again, it is not currently functional. If you want to take a look and help (send patches/suggestions, etc.) that would be welcome. Doug -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] warning for transmit data with benchmark_tx.py
Hi, i run usr/local/share/gnuradio/examples/digitals$./benchmark_tx.py --freq=2.4G this give warning following: >>>gr_fir_fff: using SSEwarning : failed to enable realtime scheduling what is the problem? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code for current release (3.1.3)?
maybe you can use the numpy instead of Numeric Yihu Li wrote: > > Hi everyone, > > I am new to gnuradio and plan to do some cross-layer implementation (MAC > and > PHY layers with MIMO) on gnuradio. I intalled the newest stable version of > gnuradio (v3.1.3) and plan to use BBN 802.11 code or span80211b with it. > However, it seems that BBN 802.11 and span80211 code can only be used with > the earlier version of gnuradio (see https://www.cgran.org/wiki/Projects > ). > I read the emaillist archieve and found some people were discussing this > and > working on it. What is the newest updates about this? Does anyone > successful > use it this way? > > Thank a lot. > > Yihu > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/updated-BBN-80211-code-for-current-release-%283.1.3%29--tp20826235p20829581.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] warning for transmit data with benchmark_tx.py
Hi, i run usr/local/share/gnuradio/examples/digitals$./benchmark_tx.py --freq=2.4G this give warning following: >>>gr_fir_fff: using SSEwarning : failed to enable realtime scheduling.. what is the problem? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
