WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2009-Jan-23 03:40:44

varasan
Member
Registered: 2008-Oct-07
Posts: 4

Exercise 4 Nomac testing

I am trying to test lab exercise 4 (Nomac). I have only one FPGA board to do this experiment. So the following was the setup which I had used.

http://i404.photobucket.com/albums/pp122/adrenalcoyote/Drawing3.jpg

I used PC 1 to download the bitstream to the FPGA board. PC 2 and the FPGA board are connected to the switch. No other devices were connected to the switch. There is also a wireless network present in the area of my setup. When all the systems were running, I could see wireless activity in FPGA board. (The led on the radio controller was glowing). I had wireshark in PC 2 to check whether PC 2 received any packets. But, wireshark didn't detect any packets.

Is my setup wrong to test this kind of exercise? If so, how do I test this exercise using only one FPGA board.

Offline

 

#2 2009-Jan-23 10:37:07

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Exercise 4 Nomac testing

The PHY and MAC in the OFDM reference design do not interoperate with IEEE 802.11. These designs are built for networks built from multiple WARP nodes, each running the same MAC/PHY design.

Offline

 

#3 2009-Feb-05 23:49:19

shettysid
Member
Registered: 2009-Feb-05
Posts: 6

Re: Exercise 4 Nomac testing

Hi Patrick

I am trying to set up Lab4 using two WARP nodes. My set up: Tx side = Laptop with a private IP + WARP node connected using crossover Ethernet cable. Rx side = same as Tx side.
Before I shoot my question here is an observation regarding the instructional manual for LAB4. I am assuming that that Section 2 Step5 should mention that the project NoMAC needs to be 'Mark to initialize BRAM' and other projects should not be 'marked'.

With this done I loaded the NoMAC bit file onto 2 WARP boards (my assumption is that the 'sink' node is loaded with the NoMAC code). I do see the pings (aka ICMP echos packets) being transmitted by the Tx radio (as observed on the SA) but I do not get a reply. At the Rx I can see the user LEDs changing states but I see patterns that I cannot explain: All 4 LEDS (high and low) sometimes change states all the same instant. I do not expect to see this because if I understand correctly (through warpmac_incrementLEDHigh () and warpmac_incrementLEDLow () function definition) a packet can be either good or bad which means I will see only 2 out of the 4 LEDs change states at any given instant.
In fact I am not even sure if any packet is being transported from the radio to the Ethernet port (is there a way to check?).

Thanks and Best Regards
sid

Offline

 

#4 2009-Feb-06 13:26:53

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Exercise 4 Nomac testing

With so many pieces interoperating, it's best to start decoupling things to debug the problem.

1) Make sure your Ethernet cables and NICs work; try connecting your PCs together directly and see if pings work.
2) Hard-code ARP entries for each PC on the other. If the ARP resolution process fails, Windows will generally give up and drop outgoing packets (you'll think you're sending pings, but aren't really)
3) Install a packet sniffer (like Wireshark) on each machine, to see what packets are actually being transmitted and received. We've seen cases where Wireshark will show an ICMP echo request being received, but Windows chooses to ignore it (dropping it at the firewall, for example).

Offline

 

#5 2009-Feb-06 18:46:15

shettysid
Member
Registered: 2009-Feb-05
Posts: 6

Re: Exercise 4 Nomac testing

Hi Everyone

Tried Wireshark and I do see the packets making to the Rx PC but the PC side does not for some reason . But the PER seems to be very high (~80%). We have moved the set up from radiated to conducted with a variable attenuator to limit interference and to test the link over a range of RSSI conditions (AGC effects). We have also made sure Tx DC offset is calibrated.

Its a single Tx-Rx pair and we are unidirectional UDP packets such that there is no 'reply' message being sent by the Rx side.

Is this something you have observed?

Thx and regards
sid

Offline

 

#6 2009-Feb-06 20:20:01

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Exercise 4 Nomac testing

A few things:

-How are you measuring the PER?

-Are you using the latest ref design (v11.2)? If you're using the project from the workshops page, try switching to the ref design. NoMAC is one of the applications included with the v11.2 XPS project.

-Try using a different RF channel; anything in [1,14] is valid for 2.4GHz.

-Did you change the modulation scheme for packet payloads (it's QPSK by default).

Offline

 

#7 2009-Feb-10 22:12:42

shettysid
Member
Registered: 2009-Feb-05
Posts: 6

Re: Exercise 4 Nomac testing

Answers embedded below...

A few things:

-How are you measuring the PER?
Send a packet every 1 sec and monitor how many packets make it through to the Ethernet interface (using Wireshark)

-Are you using the latest ref design (v11.2)? If you're using the project from the workshops page, try switching to the ref design. NoMAC is one of the applications included with the v11.2 XPS project.
Tried it, didnt seem to make any difference

-Try using a different RF channel; anything in [1,14] is valid for 2.4GHz.
Tried it, in the case of the lab refdeisgn looks like a slight improvement in PER when I witch to Channel 6 but bad nonetheless

-Did you change the modulation scheme for packet payloads (it's QPSK by default).
I am assuming that the only change needed for this is to set the HDR_FULLRATE to BPSK in the header within the emacRx_callback() function.
Result: No improvement... Something else going on..

Offline

 

Board footer