You are not logged in.
Hi Murphypo,
I think there is an inconsistent issue between Simulink design and Warp Phy in the header structure.
In OFDM_MIMO_mdl(2.01.r), the last two bytes (byte 22, 23 starting from 0) are CRC bytes of the header. This is defined in the OFDM_init_tx.m. However, in warpphy.h, the header structure is defined as follows:
typedef struct {
///Full-rate modulation order
unsigned char fullRate;
///Rate for convolutional error correction code
unsigned char codeRate;
///The length of the packet (in bytes). NOTE: This should only specify the length of the payload to-be-sent.
unsigned short int length;
///Source MAC address.
unsigned short int srcAddr;
///Destination MAC address.
unsigned short int destAddr;
///Relay MAC address.
unsigned short int relAddr;
///Type of packet this particular Macframe corresponds to (e.g. DATA, ACKPACKET, etc.)
unsigned char pktType;
///Sequence number of this packet
unsigned char seqNum;
///Reserved byte
unsigned char reserved1;
///Reserved byte
unsigned char reserved2;
///Reserved byte
unsigned char reserved4;
///Reserved byte
unsigned char reserved5;
///Reserved byte
unsigned char reserved6;
///Reserved byte
unsigned char reserved7;
///Reserved byte
unsigned char reserved8;
///Reserved byte
unsigned char reserved9;
///Reserved byte
unsigned char reserved10;
///Checksum of the packet will be automatically inserted by PHY
unsigned short int checksum;
///Reserved byte - must be zero for coded PHY
unsigned char headerTail;
} phyHeader __attribute__((__aligned__(8)));Byte 21, 22(starting from 0) are CRC bytes and the byte 23(last one) is the headerTail byte. What is the headerTail byte? Does Simulink model also consider this byte?
Also, I think you use one reserved byte for sequence number, right? I think you have used 15 byte in total based on the header structure in warpphy. Can I use all the rest of 9 bytes to append extra information? What is the exact position of those bytes in the real phy? Are they in byte 12-20(starting from 0)?
Thanks a lot,
Tan
Last edited by tan (2010-Aug-14 21:59:41)
Offline
A long time ago, one version of the PHY included a convolutional error correcting code. It was special-built for a demo, and never made it into the sequence of reference designs. The code required tail bits to terminate the encoder after the header and after the payload. In this design, the last byte of the header was always zero, and the two preceding bytes were the 16-bit checksum. In the uncoded (i.e. current) PHY, the tails aren't needed. The header checksum is the last two bytes, the payload checksum is the last four, and NUM_PAYLOAD_TAIL_BYTES=0.
I agree the phyHeader typedef is inconsistent- the checksum really does occupy the last two bytes (indices 22:23). So header bytes [0, 2:3, 22:23] must be left alone (for modulation order, length and checksum). It's safe to modify the rest as needed.
Offline
Thanks for the timely reply!
However, if I want to use the CSMAMAC, I think I should keep [0:11, 22:23] unchanged, right?
Tan
Offline
Yeah. CSMAMAC cares about the packet type, src/dest addresses and sequence number. The other bytes are safe to overload. Keep in mind the PHY doesn't care about these bytes, so you can safely customize CSMAMAC's field usage (say, by shrinking addresses to 4-bits, and storing src/dest in a single byte). Be sure to keep the auto responder configuration in sync (it's looking for addresses and types in particular bytes to trigger ACK transmissions).
Also, just for clarification, we changed the phyheader definition slightly in v15 (see warpphy.h). We needed bigger sequence numbers for some long tests we're running, so it's a short now (instead of a char, as in pre-v15).
Offline
Thanks for the reply!
Tan
Offline
Hi Murphypo,
Before testing BER of my design, I plan to first write two simple UDP programs(Server and Client) and verify the functionality of my design in real hardware. The program is pretty simple: First, client sends a certain number of bytes to server; second, server sends whatever bytes received back to client; finally, client compared the sent byte and the received byte to check the correctness. The code works fine in your original design but breaks in my design.
I think the possible reason is that I didn't configure the length information correct.
Currently, my design only works fine for the number of payload bytes which is the multiple of 4, say 1200 bytes. Hence, the length of char string I sent is 1200 byte(before it get transmitted to Warp board). My question is will a Ethernet header will be appended to my char string to make it longer? I checked the API manual and I think there is a Ethernet header which is 18 byte long. In warpmac_prepPhyForXmit(), packet->header.length = packet->header.length + NUM_HEADER_BYTES + NUM_PAYLOAD_CRC_BYTES + NUM_PAYLOAD_TAIL_BYTES; Does the original header.length(which comes from Ethernet) contains sizeof(Ethernet Header)+sizeof(Ethernet Payload) or just sizeof(Ethernet Payload)?
I'm sorry I have very limited background in networking and really appreciate your help!
Tan
Offline
I would suggest installing Wireshark to observe exactly what the Ethernet packets look like on the wire. You can run Wireshark in parallel with other networking apps on the same PC.
Offline