You are not logged in.
Dear Sir,
i want to know what is the packet size in COGMAC and from where we are able to see or set this packet size ????
thanks
Offline
When using Ethernet as the source for traffic, the packet size is simply the size of the incoming Ethernet frame-- we don't set it explicitly. The size of the Ethernet frame is determined on line 544 of warpmac.c and is passed to the user callback on line 587 of warpmac.c. The easiest way to change the size of the over-the-air packet is to change your computer's Ethernet MTU.
Alternatively, if you don't want to use Ethernet-sourced transmissions, you can use the dummy packet mode that is built into WARPMAC. In this mode, your transmitter will have randomly generated bytes to send at regular intervals. The size of these transmissions are set on line 129 of warpmac.c.
Offline
thank you sir
i got it
i have another confusion that COGMAC is using the CSMA protocol or something else ??
i mean what protocol COGMAC is using ??
once aging thank you sir for help
Offline
It's CSMA/CA. In fact, cogmac.c is a variant of csmamac.c that we built for a WARP workshop to showcase a very simple channel hopping application.
Offline
Hi,
I'd like to know what's the maximum packet size one can use? I read somewhere that the max is 2047 bytes but I tried with larger size and it seems to work, so I would like to know what the limit is.
Thanks!
Offline
The 32 transmit buffers, 2048KB each, are aligned sequentially in hardware (BRAM block). If you carefully handle these buffers (no overwriting/modification of later buffers) it might be possible to transmit longer packets. The length field in the header theoretically supports lengths up to 2^16-1 Byte, which is enough for 32*2048 Byte. Yet, I do not know if there are "hidden" limitations in the PHY implementation that truncate packets after 2048 Byte.
Last edited by Christian (2013-Jan-31 04:12:37)
Offline
By default, the total packet size limit (including header, checksum) should be 2048 bytes. If you don't mind me asking, how are you verifying that it works with larger? What may be happening is that the 2048-byte packet buffer is wrapping on itself, so the end of the packet winds up overwriting the beginning of the packet. The checksum might still work for the longer packet, so that could explain why the PHY is reporting a good reception when, in reality, the received packet buffer has only 2048 bytes of that longer received packet.
There is an untested, somewhat hidden, feature of the PHY that puts it into "big packet buffer mode" that may work for you. Instead of having 32 different 2K buffers, the same memory space is treated as 4 different 16KB buffers. Note: there is going to be some limit where sampling frequency offset limits your ability to receive long packets, and I suspect that limit will occur before the full 16KB theoretical length.
To enable this mode, you need to write a 1 to the 4th least significant bit in the Rx_ControlBits register (i.e. hex 0x8). There is already a #define for it in warpphy.h on line 151 that you can include wherever 'mimo_ofdmRx_setOptions' is currently called. Even though that function is used for Rx options, I just checked in the logic and it appears that the particular bit in question for big packet mode applies to both Tx and Rx. So, you only need to set it using the 'mimo_ofdmRx_setOptions' and not the equivalent function for tx control options.
Offline
Just to add to Chris' post re: big packet mode- when this is enabled you can only use packet buffers 0, 1, 2 and 3. This is true for both both code (i.e. calls to warpmac_startPhyXmit(ind)) and auto-responder configurations.
Offline
Thanks for the answers. I was saying bigger packet size "works" because I got good packet call back from PHY and I have observed a longer transmission time of the packet with bigger size. But I didn't check the actual length and content of the packet which i just assumed to be received correctly. I will check that.
Offline