[Discuss-gnuradio] Connect two daughterboards with a coax cable.
Hi, I 'd like to connect two daughterboards (on two separate USRP boxes) with a coax cable. The cable will replace the two RFX2400 antenna. What kind of coax cable do I need to buy? Anyone has any experience? Thanks. David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: polymorphic type documentation (PMT)
Eric, George: I have another question. According to the mblock design documentation (from BBN) it's capable of handling both message blocks and gr blocks at the same time. Is this true in the current implementation? Does this mean we can utilize the existing gr DSP blocks inside a mblock? - David On Tue, 2008-04-29 at 01:03 -0700, Eric Blossom wrote: > On Mon, Apr 28, 2008 at 10:11:47AM -0700, David Li wrote: > > > > 1. In section "Constructing / Assigning a PMT": isn't pmt_list part of > > this too? > > > > FWIW, there's no list type. A list is built from the empty list > (PMT_NIL) and pairs (conses). It's pretty much isomorphic to scheme > and lisp data types. > > To save George some typing, you may want to just look at > the doxygen header comments in pmt/src/lib/pmt.h or > http://gnuradio.org/doc/doxygen/pmt_8h.html > > Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: polymorphic type documentation (PMT)
George, Thanks for coming up with the doc so fast. This helped a lot! A few comments: 1. In section "Constructing / Assigning a PMT": isn't pmt_list part of this too? 2. In "PMT Conversion Methods": what's the difference between using a "construction method" and a "conversion method" to generate a PMT type? For example, one can use either pmt_integer(long) or pmt_from_long() to get a pmt long type. - David On Sat, 2008-04-26 at 00:36 -0400, George Nychis wrote: > Hi all, > > I've added documentation on the new polymorphic type in GNU Radio, PMT, > to the GNU Radio wiki: > http://gnuradio.org/trac/wiki/TypePMT > > It has full details of many of the methods, how to use a PMT, how to > assign it values, how to do type conversions, etc... > > For more difficult PMT types (lists, dictionaries, etc...), I have added > detailed sections. > > This is all part of my attempt to make a better wiki... > http://gnuradio.org/trac/wiki/WikiStartNew > > ... I'm branching out from the m-block info, slowly but surely! > > - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] m-block timeouts, time passed
Hi George, I browsed through cmac.cc and got a few questions: 1. Can you explain more about "Without m block to gr block connection, all raw samples are forced thru the MAC layer"? 2. What kind of applications are needed to interface with your MAC code to do CS configuration and data transfer/receive? 3. What are those PMT related macros? Perhaps it's easier if there exists documentations explaining the current mblock implementation. The bottom line is this is interesting enough and I 'd like to give it a try. You can email the directions to me offline. Thanks. - David On Thu, 2008-04-24 at 13:30 -0400, George Nychis wrote: > > David Li wrote: > > > > Hi George, > > > > I am interested in your MAC work. Does it run in the kernel or user > > space? Does it interact with IP? > > > > Is there a branch that I can download and play with it? I have two USRP > > 2400 boxes. > > > > Hi David, > > Put your reading glasses on. > > To do MAC work in GNU Radio, you need to use the m-blocks which allow > meta-data with message passing in the framework. They're extremely > flexible blocks. These blocks have been officially released with GNU > Radio and I have been using them for quite some time with no issues. > > However, to do MAC work, you also need to use what we call inband > signaling. This functionality is a work in progress within GNU Radio > and is scheduled to be released with the next major GNU Radio release. > The inband signaling functionality adds a control channel between the > host and the USRP, as well as meta-data which as passed on the USB > blocks of samples for tighter timing control for TDMA and such. > > Additionally, my research group at CMU has made additional FPGA and host > changes to support time-critical common MAC functionality in the FPGA, > with completely control at the host using the control channel. It's > sort of like an addon in terms of functionality of the in-band > signaling. For example, we implement a 96 coefficient matched filter in > the FPGA to support several things: > >- squelching of samples to the host until a sequence is detected > (prevents constant demodulation at the host, great for packet detection) > >- generation of dependent packets --> for example, when a packet is > detected in the FPGA and it's detected that its for this host, trigger > the transmission of pending samples (like a pending ACK). This reduces > ACK turnaround time, which in turn increases capacity. This could also > be used to generate some sort of synchronization responses in TDMA quickly. > > We also implement carrier sense on the board, with control by the host > on a packet basis, to reduce the size of the carrier sense "blind spot" > introduced by the bus latency. > > Our goal has been to argue against the traditional streaming based > architecture of software-defined radios, for a new architecture which > can support MAC development. > > There are 2 more "gotchas" in terms of GNU Radio. There is no > m-block->grblock connection, which means you can't use 99% of what is in > GNU Radio with the in-band work or our additional work so far. Lastly, > there is no C++ daughterboard control which limits things even further. > I wish I could give a timeline of this functionality being available, > but I have no clue :) > > Our group, with the help of Dan (another student at UW), has worked > towards temporary work arounds while waiting on this functionality. We > implemented a hacked up version of GMSK in an m-block, so its the only > PHY currently supported, and we hacked up initialization of the > daughterboards in python and passing the reference to our m-blocks via SWIG. > > We have a simple file transfer application working on the USRP with any > daughterboard using a basic CSMA protocol: > https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/macs/cmusdrg_macs/trunk/src/lib/cmac.cc > > It does addresses, ACK's, ACK timeouts, and carrier sense. Some > students in a class are working on extending it to random exponential > backoff (fairness) and sequence numbers (ACK-loss resilience). > > I'm also working on a TDMA MAC right now, sort of layed out here: > https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/wiki/TMAC > > If you're interested in playing around with it until the missing GR > functionality is implemented, you can contact me off list and I can pass > you a series of patches. That's my own personal support towards my own > work which I want people to use. Once it hits GNU Radio mainstream, > then you will be able to find support on the list. > > - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] m-block timeouts, time passed, or
Hi George, I am interested in your MAC work. Does it run in the kernel or user space? Does it interact with IP? Is there a branch that I can download and play with it? I have two USRP 2400 boxes. Thanks. - David Li > > Eric Blossom wrote: > > What your asking for would be hard to do using the existing > framework. >> I still don't understand where you want to do this from. That is, >> which code would be making the determination that it was time to pause >> or unpause the timer. >> > > For instance, a new node enters a backoff state and decides that it > needs to wait for the channel to be idle for 10ms before it can > transmit > (802.11 like). It starts a one shot timer for 10ms, and with each new > RSSI reading from the PHY, which comes at variable times due to > processing and queues, the protocol checks if the new RSSI reading is > greater than some CCA threshold. If it's greater, it needs to pause > the > timer because the timer represents the time at which the node must wait > when the channel is idle, not busy. Once the RSSI drops below the CCA > threshold, it can then resume the timer. Once the timer fires, the > node > attempts to transmit. > > - George > > > > > -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A file_sink question
When I tried to dump audio stream data into a file_sink, I found this was doable on a Ubuntu 7.10 with Python 2.5 but not on a FC6 with Python 2.4. I had no clues so far why this happened. Any ideas? Thanks. - David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hier_block2 and message_source
Hi, I have two classes A and B both derived from hier_block2. A also contains a message_source. The intention is to connect A with B inside a top_block: class A(gr.hier_block2): def __init__(self): self._source = gr.message_source() class B(gr.hier_block2): I connect the message_queue (in A) with B in a top_block like: connect(A._source, B) run() The subsequent run() command crashed with: python: /usr/include/boost/shared_ptr.hpp:253: T* boost::shared_ptr::operator->() const [with T = gr_basic_block]: Assertion `px != 0' failed. Aborted Did I connect the wrong components? Thanks. - David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "max recursion depth exceeded" error solved and new problem playing sound
It turned out I forgot to init the top block. So this problem is gone.
The new problem is I can't make the receiving machine to play a sound.
The client is sending a sine waveform like this:
class Client2(gr.top_block):
def __init__(self, addr, port):
gr.top_block.__init__(self, 'client2')
self._locatie= (addr, port)
self._clientsock = socket (AF_INET, SOCK_STREAM)
self._clientsock.connect(self._locatie)
self._src = gr.sig_source_f(44100, gr.GR_SIN_WAVE, 500, 0.8)
self._file_sink = gr.file_descriptor_sink(gr.sizeof_float,
self._clientsock.fileno())
def connect(self):
try:
self.connect(self._src, self._file_sink)
except Exception, e:
print 'client2 connect failure:',e
def run_client(self):
self.run()
print ' client is running '
def stop_client(self):
self.stop()
self.clientsock.close()
print ' client is stopped '
if __name__ == '__main__':
address = sys.argv[1]
port= int(sys.argv[2])
print ' Trying to connect to:', address, port
c = Client2(address, port)
c.run_client()
while True: pass
#c.stop_client()
print ' Done sending waveform to server!'
And the server on the receiving machine is receiving like this:
class Server2(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, 'server2')
self._serversock = socket(AF_INET, SOCK_STREAM)
#serversock.bind has to use "" for other clients not on
#the same host
self._serversock.bind(("", 12345))
self._serversock.listen(1)
print 'Ready to receive sin-wave file'
sys.stdout.flush()
def start_listen(self):
self._clientsock, self._clientaddr = self._serversock.accept()
print 'Got client connection', self._clientsock,
self._clientaddr
sys.stdout.flush()
try:
self._filesrc = gr.file_descriptor_source(gr.sizeof_float,
self._clientsock.fileno())
self._audio_sink = audio.sink(44100)
self.connect(self._filesrc, self._audio_sink)
except Exception, e:
print ' Error in start_listen: ', e
def run_server(self):
self.run()
if __name__ == '__main__':
s = Server2()
s.start_listen()
s.run_server()
On Thu, 2008-03-06 at 16:00 -0800, Johnathan Corgan wrote:
> On 3/6/08, W. David Li <[EMAIL PROTECTED]> wrote:
>
> > I got this error when connecting a file_descriptor source to an audio
> > sink in a top_block. Any ideas what might have gone wrong?
>
> That error can happen if you try to access a method name of a
> hierarhical block that doesn't exist. Look for a typo.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] "max recursion depth exceeded" error
Hello, I got this error when connecting a file_descriptor source to an audio sink in a top_block. Any ideas what might have gone wrong? Thanks. David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] kludge_copy question
Hi, I have a class that inherits from "gr.kludge_copy". For now this class does nothing but to copy the inputs to outputs: class MyClass (gr.kludge_copy): def __init__(self, size): gr.kludge_copy.__init__(size) I might not have done something correctly so when I used MyClass as one of the blocks in my flow graph, the error was: TypeError: Error when calling the metaclass bases function() argument 1 must be code, not str I looked at the kludge_copy QA code. It's used as a standalone not an inherited object. So am I using it correctly in MyClass? Thanks. - David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr.message_source question
Hi, I got a python class that contains a gr.message_source as in the following. When UDP packets came in "enqueue_pkt" was called. Packets were converted into stream and inserted into a gr.msg_queue. Now I tried to dump the stream to an audio device by connecting the message_source to an audio sink. I got an error message: audio_alsa_sink[hw:0,0]: Device or resource busy What went wrong here? - David code snipets --- class source(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, "local_vrf_source", gr.io_signature(0,0,0), gr.io_signature(0,0,0)) self._message_source = gr.message_source(4) #Is this the right size? self._message_queue = self._message_source.msgq() def enqueue_pkt(self, pkt): """This will take UPD pakcets, converts them into stream gr_messsage and enqueue to the message queue """ try: msg_sptr = gr.message_from_string(pkt) self._message_queue.insert_tail(msg_sptr) audio_sink = audio.sink(48000) self.connect(self._message_source,audio_sink) except Exception,e: print 'source: exception: ', e - end of code snipets -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help: make problem with 3.1.1 on 64 bit FC6
Hello, I have a 64 bit machine with FC6. Downloaded the 3.1.1 release tar ball and unpacked it. Did ./configure and everything was fine. Under regular user name I did 'make' and kept getting errors shown below. Never had this problem with previous releases. Anyone has any idea what's wrong? - David Making all in gengen make[5]: Entering directory `/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src/lib/gengen' PYTHONPATH=../../../../gnuradio-core/src/python srcdir=. /usr/bin/python ./generate_all.py Traceback (most recent call last): File "./generate_all.py", line 33, in ? generate_all () File "./generate_all.py", line 28, in generate_all generate_common.generate () File "/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src/lib/gengen/generate_common.py", line 90, in generate expand_h_cc_i (root, s) File "/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src/lib/gengen/generate_common.py", line 72, in expand_h_cc_i expand_template (d, root + '.h.t') File "/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src/python/build_utils.py", line 55, in expand_template template = open_src (template_filename, 'r') File "/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src/python/build_utils.py", line 106, in open_src return open (os.path.join (srcdir, name), mode) IOError: [Errno 2] No such file or directory: './gr_sample_and_hold_XX.h.t' make[5]: *** [gr_argmax_fs.h] Error 1 make[5]: Leaving directory `/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src/lib/gengen' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/wdli/workspace/svn/LMWET/trunk/gnuradio/gnuradio-3.1.1' make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make install
Hi , This is a problem that kind of a nuisance: every time I do make install gnuradio on this particular machine, I see many similar messages to the following: mv: cannot move `libgnuradio-core-qa.so.0.0.0' to `libgnuradio-core-qa.so.0.0.0U': Permission denied And every time I have to manually change the permission of the .lib directories. I don't think this is a gnuradio issue but maybe something on this machine I need to change. Just wonder if anyone knows why. Thanks. - David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP assembly instruction
Hi All, My USRP package comes in without any assembly instructions. I didnt find any at The Ettus Research web site. Just to make sure I don't do something silly - isn't the fan suppose to be on top of the Altera Cyclone chip by glue pins? Are there any special attentions I need to pay when installing the RFX2400? Any pointer to instruction would be helpful. Thanks. - David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Newbie question: gnuradio configure with USRP
I have USRP board with RFX2400. The question is how GnuRadio should be configured/compiled to use USRP. Before this I configured/compiled 3.0.4 without USRP (using ./configure, make and make install). ./configure showed: The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp gr-usrp gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-wxgui This made me wonder if I need to something different this time. Thanks. - David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
