discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Some observations getting a MAC protocol to work


From: Ges
Subject: [Discuss-gnuradio] Some observations getting a MAC protocol to work
Date: Wed, 10 May 2006 19:40:44 -0700 (PDT)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]