Forum: GNU Radio Some observations getting a MAC protocol to work

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
628baa3c453c0bd218cb4d07363cad15?d=identicon&s=25 Ges (Guest)
on 2006-05-11 04:43
(Received via mailing list)
Hi Eric,

I am working on a TDMA MAC protocol using Gnu Radio blocks with Click.
My setup consists of 2 USRP boards connnected to 2 machines. The USRPs
are connected to each other using SMA Tees (2 tx and 2 rx daughter
cards). So I have a shared media where the rx daughter cards can hear
all that is being transmitted.
I am using the GNU Radio blocks as Click elements and I use the single
threaded scheduler to process the flowgraph of blocks inside Click.
Click helps me to do the MAC layer control mechanism. I use a
combination of timers and tasks to schedule the transmits; the reception
is a continuously rescheduled task.

These are some of the issues I faced when I tried to get the TDMA to
work:

1. Each packet is 54 bytes payload plus 8 bytes sync overhead plus 1
byte tail overhead. A packet gets transmitted across neatly - and i get
the payload of the packet in a file. This is using the new changes to
the GNU Radio - latest CVS update. I was earlier using the old one - 2.5
I think - using that to send this same packet across I had to send out
over 58 overhead bytes to make sure that the complete packet left the
gnuradio blocks. Some of the data would not get completely processed by
some of the blocks (the FIR filters I think).
But with the changes in the single threaded scheduler - with the way it
computes "noutputs" and "the "ninputs_items" things were a lot better.
The new scheduler seems to make sure that almost all the data gets
cleared. And hence I was able to send the 64bytes without any additional
overhead.

The gnuradio blocks do not get data of the next packet till the first
packet was sent out of the system. I have to ensure packet boundaries.

2. But when doing the TDMA, I notice the following. If after sending one
such packet from node A to node B and now if node B is sending a
different 64 byte packet (only the payload is different) to node A , the
packet that node A receives gets mangled.

But if only node A sends 2 packets to node B, both the packets get to
node A conrrectly - i.e. I can retrieve the payload correctly -

Packets get mangled when a receiver processes data from different nodes
alternatively.

My understanding is that this is again related to the blocks having some
data left  in its  buffers that is damaging the other packet.
Because if both the packets are from the same node, then this is does
not happen.

Am I right that this is due to the buffers or is there some other
possible reasons for this.

Related to this, is there a way for me to clear the buffers of all the
blocks after sending and receiving  packets.  Will resetting the
d_write_index and d_read_index of each buffer do the trick?

Comments on this would really help clear my understanding and maybe even
improve my approach.

Thanks
Gesly
This topic is locked and can not be replied to.