You are not logged in.
I changed the modulation for the packets fullrate symbols from QPSK to 1) QAM16 and 2) QAM64. While receiving, I oberseved that packets with bad header are received. This happens for QAM64 much more often than for QAM16. Almost every second received packet causes a bad header event with QAM64.
The curious about this is that all send packets arrive at the receiver as good packets without having been retransmitted. In my setup there is no disturbance and sender and receiver are only 1-2m away from each other. The sender does not wait for acks and the receiver does not send acks. The sender just sends one packet after the other in time intervalls of 1 second. And every second one packet is errorless received at the receiver.
The bad header event therefore seems not to be caused by the send packets. All send packets arrive without retransmissions, in a constant time intervall (1s). But in between the reception of these packets bad headers are indicated. Also these bad header indications occur in constant time intervalls. If the bad header event is caused by the send packets, than the receiving intervalls wouldn't be constant and retransmission would occur. This does not happen. I can exclude that other senders are in reception range. Using QPSK this phenomenon does not occur.
My only explanation for this phenomenon is that maybe the PHY on sender side transmitts some something in between the sending of packets and that this is perceived as bad header at the receiver. Is this possible?
Or is there an other explanation? What else besides a really send packet can cause a bad header event on receiver side?
Thanks,
Last edited by domenique (2009-Jan-17 04:03:18)
Offline
The bad header interrupt handler is actually called when either a packet header has an error, or when a packet header was good but its payload had an error. This is a workaround for a bug in the PHY, which would occasionally raise the bad packet interrupt, even if configured not to (fixing this is on our list :-). What you're seeing is probably a larger number of bad packets when you raise the modulation rate. These errors shouldn't be in the headers (since the headers are still QPSK).
Offline
Hi.
I was wondering what is the minimum time between two packets(having payload data) that PHY can process/send/receive in (payload)QPSK.
I am getting bad headers occasionally on the receiving end after sending control packet(made in warp(header and some payload(16B))) and then datapacket(from PC (1024B)).
The control packet is received perfectly but some DATA packets headers after that are bad/corrupted. Just wondering if i am sending them to fast... As in the CSMA MACs and NOMAC implementations time between two received packets might be longer compared to my approach.
Offline
murphpo wrote:
What you're seeing is probably a larger number of bad packets when you raise the modulation rate. These errors shouldn't be in the headers (since the headers are still QPSK).
This can be the reason. Because there are no resends and all send packets arrive. If it really was a bad packet, I would either see a resend or a packet would be missing. But all packets arrive in time intervalls of 1 second. But in between I get bad headers, even though I'm sending only in time invtervalls of 1s.
I don't know what the reason could be.
@HT:
I had a similar problem. I tried to send as fast as possible without waiting for acks and observed, that some packets were not received. I solved this by a timeout of ~10 time slots, after each sending process. By doing this all packets were received.
Offline
The Rx PHY does require a minimum time from receiving the last sample over-the-air and starting a new packet reception. This is due to the latency of Rx processing; the PHY needs to finish processing one packet, deciding whether it was good or bad, before it can begin processing the next. Using noMAC, it is definitely possible to send packets so fast (i.e. with a high enough duty cycle) that the Rx PHY will miss alternate packets. This doesn't occur with CSMAMAC, of course, as it waits for an ACK before starting a new transmission.
Offline
Thanks.
My problem was not so much related to this but I found as i was queuing the data packets (eth payload) there was one thing that i didn't queue the value of numFullRate symbols in warpmac_prepPhyForXmit function.
So as i sent the small control packet in middle of intense Ethernet traffic it changed the value numFullRate and that messed up the next data packet. As numFullRate value is used in warpphy_setNumSyms macro(regwrite) in every TX of a wireless packet.
I was wondering which way you see easier to add more control bytes to the data flow in WARP.
Make the header bigger example 24->36Bytes or tweak the place where dma copies the ETH packet into the PHY tx-buffer so that there is room for some control information to be carried along the data transmissions ?
Offline
You can add bytes to the header with changes to just C-code, as the PHY only needs to know how many base rate OFDM symbols to send. But both the Tx and Rx need to agree on this ahead of time; the PHY doesn't support communicating header length as a field in the header itself.
Offline
Yes... But what about already existing header (24B) on your refdesign. As the phy insert checksum of the header always on the same place/location on the header, right ?
So making the header longer doesn't have any effect on this location, example if phy calculates the checksum of the new bigger header, so does the phy inserts that checksum on the same place as before?
On the other hand tweaking the fullrate symbols area would be more flexible as i don't need more header bytes all the time. Any idea of how many fullrate symbols is the max in one OFDM frame ?
Offline
There's a register in the PHY that configures the number of header bytes. The checksum block uses this value to define where the 16-bit checksum goes (always the last two bytes of the header). This value is one field in the byteNums register; see line 265 of warpphy.c for an example of writing this register.
I strongly suggest playing around with these values in simulation before trying them over-the-air. All of the PHY's configuration in simulation is handed by the init m code.
The PHY can handle hundreds of OFDM symbols per packet. But the maximum is practice is defined by the 1500 bytes in a maximum-sized Ethernet frame.
Offline
Hello,
What about changing the modulation per subcarrier and giving the modulation type for each subcarrier in the header? Would there be enough time after the header is received to set the modulation masks in the shared memory in the C code or is it needed to make changes to the System Generator model?
Thanks!
Offline
The PHY model currently supports changing the modulation per subcarrier but does not automatically include this information in the header. The Rx PHY could be modified to use per-subcarrier modulation information from the header (it currently uses a single field to set the modulation for all subcarriers).
Offline
Hello, thanks for your answer.
Yes, there is a single header field that specifies the fullrate at each antenna. Now, if I enlarged this field to carry the modulation order of each subcarrier, would I be able to read it and set the state in the demodulator in the C code by writing in the shared memory as it is done in warpphy_setmodulation but subcarrier per subcarrier?
Or would I need to implement this in the FPGA? What would then be the changes needed then in the System Generator model? In DataBuffer/HeaderDecoding I can see how to get more bytes from the header, but not what to do with them to set the demodulator.
Offline
You would need to modify the PHY model, so the receiver could extract the modulation information as the packet is arriving. In the current design, the Rx PHY extracts the modMask value from the header and uses it to demodulate the full-rate symbols which follow. This must happen in real-time (i.e. in hardware, without interaction with C code). A more sophisticated modulation scheme would need to do the same- extract the information from the header as it's arriving and use it shortly thereafter to configure the full-rate demodulator.
Offline
@domenique: What version of the refdesign were you using? I am trying out Lab 4 (NoMAC) and am getting too many packet errors. Dropping payload mod scheme doesnt seem to help in my case. You seemed to have had success with changing modulation scheme, what changes did you make to the code?
Offline
I was using the ofdm ref design 11.2 and made some modifications to the csmamac. I extended it to send and handle broadcast packets without sending or waiting for acks. With QPSK as modulation for the payload I'm getting very nice results with low error rate. QAM16 and 64 lead to high error rates in all my measurements.
Offline
We're investigating this ourselves. In some scenarios, we get great performace from 16/64 QAM. But they are very sensitive to some "magic" numbers in the MAC/PHY (thresholds for AGC/packet detection, MAC timing, etc). We're hoping to robust-ify things and post reference design v12 soon.
Offline