Carrier sense MAC / realtime / etc

I’ve just finished checking in a bunch of modifications to
gnuradio-core and gnuradio-examples. These are the culmination of
work with Matt over the past few days.

Summary: If you’re tracking CVS+SVN, now’s a good time to update:

gnuradio-core
usrp
gr-usrp
gnuradio-examples

We now have a workable carrier sense MAC.
The old tunnel_ip_null_mac.py has been removed, and is replaced
by gnuradio-examples/python/gmsk2/tunnel.py

tunnel.py enables real time scheduling if possible, and implements the
carrier sense MAC. Running with a raw bitrate of 500k, I’ve been able
to scp files across the air at aggregate throughput of about 50KB/sec.
This was tested by using scp to simultaneously pull large files from
the other node.

There was a bug in tunnel_ip_null_mac that was silently truncating
large packets, causing TCP throughput to approach zero. That’s fixed
in tunnel.py

The gmsk2_pkt.py code is now deprecated, and has been replaced by the
modulation independent pkt.py. Likewise, all the examples and support
code in gnuradio-examples/python/gmsk2 have been updated to use this.

If you’ve built similar examples, and they used the receive_path and
transmit_path.py files, your code will need a bit of work. Take a
look at the new examples to note the changes in the constructor
arguments.

The README in gnuradio-examples/python/gmsk2 has also be updated to
reflect the new reality, and to emphasize that the Linux 2.6 kernel
ships with the tun/tap driver.

Have fun!

Eric

I wasn’t sure I understood what exactly that was doing, so I looked
for some archives:

http://www.archivum.info/[email protected]/2005-11/index.html

in this e-mail you said:

“It’s an optional feature that we plan to use with
a bunch of the daughterboards. Depending on whether there’s data in
the FPGA transmit fifo or not, specified daughterboard pins
automatically change state.”

So, are you saying that if the transmitter isn’t doing anything make
certain pins on the daughterboards will be switched to receive, and
if the transmitter is doing something then the pins are switched back
to transmit??? Is this only for the RFX boards?

let me know if I’m on the right track. it sounds like its some
underlying function that doesn’t effect my work at the moment, but
its always good to have some idea of how the code you’re using works ; )

David S.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs