You are not logged in.
Hi,
I have downloaded download-nomac.bit on warp boards from OFDM_ReferenceDesign_FPGAv2_v16.1_public, but not able to ping the systems in wireless.
I have assigned IP address 10.0.0.1 to one system & 10.0.0.2 to other system. I was able to ping when they are connected via wire, ie hub.
I have even tried by downloading download-csma.bit, but not able to ping it. I want to stream a video.
I have 2 radio boards on each board.
Whenever i download bitstream (nomac or csma) on the radio board at slot 2 the yellow led glows of both the boards,but I am not able to ping.
I have even configured node 0 & node 1 for csma with ip adress 10.0.0.20/10.0.0.0 & 10.0.0.1 for my respective systems, but still not able to ping it.
There is no user led glowing in the radio board at slot 3. The board is communicating with the speed of 100mbps.
Kindly oblige.
Last edited by faizan (2012-Jun-15 03:11:18)
Offline
Serial port messages:
NOMAC v16.0
Initializing WARPMAC v13:
Initializing WARPPHY:
Initializing Radio Transmitter...
Starting TxDCO correction...
Applying TxDCO correction for radio 2
EEPROM Values for Radio Board in Slot 2
WARP Radio Board Version 7.7
Serial Number (WARP): WR-a-00000
EEPROM Hard-wired Serial Number: 0 0 2 53 E8 73
TxDCO: Applied values to radio 2 - I: -2 Q: 0
Applying TxDCO correction for radio 3
EEPROM Values for Radio Board in Slot 3
WARP Radio Board Version 7.7
Serial Number (WARP): WR-a-00000
EEPROM Hard-wired Serial Number: 0 0 4 31 B0 A
TxDCO: Applied values to radio 3 - I: -2 Q: 0
complete!
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!
Initializing OFDM Transmitter...complete!
Initializing OFDM Receiver...complet
Initializing AGC...complete!
warphphy_init done
Initializing TEMAC...
done
Initializing WARPMAC v16.1:
Initializing WARPPHY:
Initializing Radio Transmitter...
Starting TxDCO correction...
TxDCO values for radio 2 - I: -2 Q: 0
TxDCO values for radio 3 - I: -2 Q: 0
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!
Initializing OFDM Transmitter...complete!
Initializing OFDM Receiver.
Initializing AGC...complete!
Initializing TEMAC...complete!
Reference Design v16.1 CSMAMAC
Beginning main loop
NOMAC v15.0
Initializing WARPMAC v13:
Initializing WARPPHY:
Initializing Radio Transmitter...
Starting TxDCO correction...
Applying TxDCO correction for radio 2
EEPROM Values for Radio Board in Slot 2
WARP Radio Board Version 7.7
Serial Number (WARP): WR-a-00000
EEPROM Hard-wired Serial Number: 0 0 2 53 E8 73
TxDCO: Applied values to radio 2 - I: -2 Q
Applying TxDCO correction for radio 3
EEPROM Values for Radio Board in Slot 3
WARP Radio Board Version 7.7
Serial Number (WARP): WR-a-00000
EEPROM Hard-wired Serial Number: 0 0 4 31 B0 A
TxDCO: Applied values to radio 3 - I: -2 Q: 0
complete!
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!
Initializing OFDM Transmitter...complete!
Initializing OFDM Receiver...complete!
Initializing AGC...complete!
warphphy_init
Initializing TEMAC...
done
Initializing WARPMAC v16.1:
Initializing WARPPHY:
Initializing Radio Transmitter...
Starting TxDCO correction...
TxDCO values for radio 2 - I: -2 Q: 0
TxDCO values for radio 3 - I: -2 Q: 0
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!
Initializing OFDM Transmitter...complete!
Initializing OFDM Receiver...complete!
Initializing AGC...complete!
Initializing TEMAC...complete!
Reference Design v16.1 CSMAMAC
Beginning main loop
Initializing WARPMAC v16.1:
Initializing WARPPHY:
Initializing Radio Transmitter...
Starting TxDCO correction...
TxDCO values for radio 2 - I: 102 Q: 64
TxDCO values for radio 3 - I: 70 Q: 42
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!
Initializing OFDM Transmitter...complete!
Initializing OFDM
Initializing AGC...complete!
Initializing TEMAC...complete!
Reference Design v16.1 CSMAMAC
Beginning main loop
( ) Undefined command
NOMAC v16.1
Initializing WARPMAC v16.1:
Initializing WARPPHY:
Initializing Radio Transmitter...
Starting TxDCO correction...
TxDCO values for radio 2 - I: 102 Q: 64
TxDCO values for radio 3 - I: 70 Q: 42
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!
Initializing OFDM Transmitter...complete!:
Initializing WARPP
Initializing OFDM Receiver...complete! Radio Transmitter...
Initializing AGC...complete!CO correction...
Initializing TEMAC...complete!values for radio 2 - I: -2 Q: 0
Dummy Packet Mode Disabled
NOMAC v15.0
Initializing WARPMAC v13:- I: -2 Q: 0
Initializing WARPPHY:
Initializing Radio Transmitter...r...complete!
Starting TxDCO correction...ing Packet Detection...complete!
Applying TxDCO correction for radio 2
Initializing OFDM Tra
EEPROM Values for Radio Board in Slot 2
Ini
WARP Radio Board Version 7.7e!
Serial Number (WARP): WR-a-00616 AGC...complete!
EEPROM Hard-wired Serial alizing
EEPROM Values for Radio Board in Slot 3
Starting TxDCO co
WARP Radio Board Version 7.7
T
Serial Number (WARP): WR-a-00621 Q: 0
EEPROM Hard-wired Serial Number: 0 0 1 AA 2D 3Avalues for radio 3 - I: -2 Q: 0
TxDCO: Applied values to radio 3 - I: 70 Q: 42Initializing Radio Receiver...complete!
complete!
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!e!
Initializing OFDM Transmitter...complete!
Initializing OFDM Receiver...comp
Initial
Initializing WARPMAC v13:
I
Initializing WARPPHY:
Initializing Radio Transmitter...
Starting TxDCO correction...
Applying TxDCO correction for radio 2- I: -2 Q: 0
EEPROM Values for Radio Board in Slot 2
TxDCO values for radio
WARP Radio Board Version 7.7
Serial Number (WARP): WR-a-00616g Radio Receiver...complete!
EEPROM Hard-wired Serial Number: 0 0 1 AA 3B 5Calizing Packet Detection...complete!
TxDCO: Applied values to radio 2 - I: 102 Q: 64OFDM Transmitter...complete!
Applying TxDCO correction for radio 3alizing OFDM R
TxDCO: Applied values to radio 3 - I: 70 Q: 42io Transmitter...
complete!ting TxDCO correc
Initializing Radio Receiver...complete! TxDCO values for radio 2 - I: -2
Initializing Packet Detection...complete!
TxDCO values
Initializing OFDM Transmitter...complete!
Initializing OFDM Receiver...complete!
Initializing AGC...complete!mplete!
warphphy_init done
Initiali
Initializing TEMAC.....
done
Applying TxDCO correction for radio 2main loop
NOMAC v1
EEPROM Values for Radio Board in Slot 2
Initializ
WARP Radio Board Version 7.7
Initializing Radio Tr
Serial Number (WARP): WR-a-00616
Starting Tx
EEPROM Hard-wired Serial Number: 0 0 1 AA 3B 5C
TxDCO values for radio 2 - I: -2
TxDCO: Applied values to radio 2 - I: 102 Q: 64
TxDCO values for radio
Applying TxDCO correction for radio 3
complete!
Initializing Radio Receiver...complete!
Initializing Packet Detection...complete!
Initializing OFDM Transmitter...complete!
Initializing OFDM Receiver...complete!
Initializing AGC...complete!
warphphy_init done
Initializing TEMAC...
doneOffline
There are any number of reasons that you may not be able to ping computers through the reference design, so you'll have to dig deeper for us to be able to help.
1) Just to rule out PC/network problems... if you directly connect the two computers over Ethernet and remove WARP entirely then you are able to ping successfully?
2) You need to narrow down whether you are seeing a transmission or a reception problem. If you tell the computer to shove a lot of traffic over Ethernet, can you see the outermost LED on Radio 2 turn on as its saturating the medium? That outer LED turns on during transmissions. If it isn't blinking, then there is no way to receive anything since you aren't sending anything. The easiest way to send a lot of traffic over ethernet is to hardcode an arp table entry to an arbitrary IP address, and start a ping stream with a very small interval between packets.
3) If you are transmitting successfully, now its time to see if you are receiving. In noMac.c, the node blinks the LEDs near the cross of pushbuttons. Does anything blink when you are sending the ping stream to the arbitrary IP address from step 2? If so, which LEDs are on/blinking?
Offline
One other thing to check- the OFDM ref design v16.1 assumes a 100Mb Ethernet connection, even on v2 kits. You'll need to force your NIC to 100Mb mode.
Offline
Thanks for the reply.
1) yes i was able to ping 2 computers on ethernet, in-fact i was able to stream a video.
2)Yes when i transmit the data the Tx led at the radio 2 glows ie green led glows.
3) when i send the ping steam from node 1 to node 2:
i) All the leds(near push button) at node 1 are blinking ie D10 & D13 are blinking , while D18 & D20 are blinking in sequence (D18-on D20-off & vise versa ). At node 2 only 3 leds are glowing D10,d13,D20.
But still when i ping i get
' request timed out'
Yes i have configured for 100Mb mode.
Kindly oblige
Offline
I'm not totally familiar with the default behavior of the LEDs for a reference design running on v2 hardware, but I *think* that behavior means that almost all of your traffic is being successfully delivered to the destination PC. Murphpo can correct me if I'm wrong about any of the below LED behaviors.
For future reference on the forums, the LED identifications are from here. The fact that D10 & D13 are solid at node 2 is a good sign. Those will increment back and forth whenever a packet is received that passes both the header and payload checksum. The fact they appear solidly lit just means that you are receiving a lot of packets. Those packets should be delivered to the destination PC.
1) Can you run Wireshark on the destination PC (node 2) and see if any of the traffic from node 1 can be seen?
2) It's possible that the reverse direction is the reason that pings are always failing. Maybe the ping requests are getting through, but the ping replies are failing for some reason. The fact that you see D18 & D20 blinking at node 1 supports this theory. Those blink on checksum failures. Can you reverse the direction of your ping stream and observe the behavior? Plug your traffic source into node 0 and your traffic sink into node 1, then observe the LED behaviors. If D10 and D13 are no longer solid on the receiving board, then we've tracked the problem down to that path.
Offline
Thanks for the reply.
How can i over come checksum failures or the problem of bad headers in Nomac.c?
Offline
The only way to reduce the amount of bad headers is to increase the SNR (move nodes closer together or increase transmission power) or to decrease the coding rate (e.g. QPSK 1/2 rate)
Offline
Hi,
Thanks for the reply.
1) Can you run Wireshark on the destination PC (node 2) and see if any of the traffic from node 1 can be seen?
The wireshark at the transmitter gives me this when i try to ping from 10.0.0.1 to 10.0.0.2
18518.414844000 Hewlett-_47:4f:49 Broadcast ARP 42 Who has 10.0.0.2? Tell 10.0.0.1
At the receiver side i get the same thing ie " Who has 10.0.0.2? Tell 10.0.0.1
10.0.0.1 is ( mac address),
Is that means almost all of your traffic is being successfully delivered to from node 1 to node 2, but ack/traffic is delivered from node 2 to node1?
But still I am not able to ping via Nomac & csma, ie ' request timed out'
The leds assigned for good header (as per source code) does a incremental blinking.
When i try & reverse it, ie node 2 to node 1, there's some junk data, couldnt find any data from ping.
I have followed all the steps which have been mentioned , i.e disabled all the firewalls
I am able to ping in the wired network, ie two computers.
Offline
You need to narrow down the possible sources of error in your setup. I would suggest disconnecting the Ethernet interfaces entirely, and using the OFDM ref design's "dummy packet mode" to transmit packets between boards.
In NOMAC in OFDM ref design v16.1, a node will transmit locally-generated packets if the DIP switch is set to a non-zero value (i.e. an ID>0). Try downloading the bitstream for NOMAC to both nodes, setting one node to ID=0 and one to ID=1. The node with ID=1 should transmit continuously (verify by looking for the green LED on the Radio Board in slot 2). The other node should indicate reception of good/bad packets via the 4 user LEDs on the FPGA board (top LEDs alternate for good packets; bottom LEDs alternate for bad packets). Swap the node IDs and repeat to test traffic in the other direction.
Keep in mind that you will see bad packets even without a hardware fault, especially when transmitting over-the-air. You would expect the packet error rate to be low when the channel is high SNR (i.e. the antennas are close together). For testing purposes it is useful to remove the antennas and connect the Radio Boards via a coax cable and attenuators. Always ensure you have 30+ dB attenuation when using a cable between RF ports.
Offline
Hi, Thanks for the reply.
As per suggestion i have tried the "dummy packet mode", ie configuring node1 as dummy & node 2 with Nomac, & vise-versa, both the nodes are receiving good packets( verfied by the LEDs) .When i configure both the nodes with Nomac, I am unable to ping, i.e in wireshark assuming from node 1 to node 2 i get these messages:
83 66.081654000 Giga-Byt_91:ab:5c Broadcast ARP 64 Who has 10.0.0.1? Tell 10.0.0.2
84 66.081665000 Giga-Byt_20:be:1d Giga-Byt_91:ab:5c ARP 42 10.0.0.1 is at "Mac address"
But it's not able to transmit at the other node.
But i reverse the ping, i.e from node 2 to node 1, there's no activity at wireshark of node 1, i.s i dont get any ping request, which i get in earlier configuration, but i get " echo (ping) request id =0x0200, seq=30209/374, ttl=128"
& also Header checksum: 0x0000 [incorrect, should be 0x34a6 (maybe caused by "IP checksum offload"?), but led D10 & D13 are glowing in sequence?
I have also tried with coax cable & 30DB attenator, but getting the same results, able to receive ping request at node 2 from node 1, but not able to transmit the ack to node 1. & in vise versa no such thing happens.
But everything works fine with Dummy packet mode.
Kindly oblige.
Last edited by faizan (2012-Sep-20 03:26:50)
Offline
But everything works fine with Dummy packet mode.
If you've verified both kits can transmit and receive wireless packets, then we can remove the MAC and PHY from the list of potential problems.
When NOMAC on node 1 is transmitting, try connecting node 0 Ethernet to the PC and running Wireshark. You should see a steady stream of packets. The packet contents will be meaningless (these are the packets generated by the dummy packet code), but there should be one packet received in Wireshark for each wireless packet received. Verify that both nodes are able to output the received dummy packets via Ethernet.
Another suggestion is to remove ARP from the equation, by hard-coding the ARP entries at both PCs.
On the PC with IP address 10.0.0.1, run 'arp -s 10.0.0.2 <MAC address of PC 2>'.
On the PC with IP address 10.0.0.2, run 'arp -s 10.0.0.1 <MAC address of PC 1>'.
Now when you run ping Wireshark should show actual ping request/reply packets (i.e. it will skip the ARP request/reply stage).
Offline
Thanks for the reply Murphpo.
Thanks for the suggestions. I just want to clarify few things.
The problem I am facing is i think with one of the two boards is bit problematic( say B1) , because when i ping from node1 to node2 ( assuming B1 at node 2 ), I am able to get ping request at node 2, but not able to transmit ping ack back, may be that's the reason the ping is not able to complete.
When i reverse the same i.e ping from node 2 to node 1, there is no data at the wireshark at node 2. I get some message at node 1 ie "" echo (ping) request id =0x0200, seq=30209/374, ttl=128" & also Header checksum: 0x0000 [incorrect, should be 0x34a6 (maybe caused by "IP checksum offload"?)"
Moreover there's no blinking of LED's on Node1 ( LED's for good headers), but i get indication of good header at node 2
Kindly oblige.
Last edited by faizan (2012-Sep-20 13:48:31)
Offline
If the locally-generated traffic test showed low PER for wireless packets in both directions, the issue is likely not the Radio Boards.
The test I suggested above will help rule out issues with Ethernet transmission (FPGA -> Ethernet PHY -> PC) at both nodes.
Offline
Thanks for the reply,
I dint think it's the problem with the radio boards, as i have tested the radio boards on the different base board they work fine.
But sometimes i dont get expected results when i plug in those Radio boards on B1 kit. I have modified warplab_siso_example_TxRx.m for single node & getting these results.
Here is snap shot for your reference
http://twitpic.com/awnpjq
I get these results only sometimes, i works fine most of the time.
Kindly oblige
Offline
Hi,
Thanks for the reply.
Verify that both nodes are able to output the received dummy packets via Ethernet.
As per your suggestion I have tried to verify the received packets on the ethernet.
i have followed the set-up as : at Node 1 I have connected the board B1 ( problematic)
When the dummy packets are transmitted from node 1 to node 2 I get the result in wire shark as ' Unknown frame ( Bogus frame), kindly find the screen shot in http://twitpic.com/awt3l8
When the dummy packets are transmitted from node 2 to node 1 I get the result in wire shark as ' Ehernet frame checksum"
http://twitpic.com/awt40k
Before performing the Nomac operation I had checked in the set up in PHY layer ( matlab for comm of radio boards), they work fine now.
Kindly oblige.
Cant able to figure it out where my exact problem is. I have tried with arp -s, but nothing worked, as I am getting the same result before, not able to get ping response (ACK) from node connected to B1.
Offline
Before performing the Nomac operation I had checked in the set up in PHY layer ( matlab for comm of radio boards), they work fine now.
Can you clarify what this means? Have you tested WAPRLab on both nodes successfully?
Offline
Yes, I have tested with both the nodes with warplab_siso_example_TxRx.m, they work fine.
As i have mentioned in my earlier posts, sometimes i dont get the expected results, but most of the time I am able to get the expected results.
But my concern is that I am not able ping in MAC layer protocol.
Offline
It seems like we've ruled out all the likely errors:
-The design is downloading correctly and the PPC is booting/executing as expected
-Both Radio Boards work for Tx and Rx, based on the two-way dummy packet tests and the one-kit WARPLab tests
-Both Ethernet interfaces work, based on the WARPLab tests
I'm not sure what else would cause ARP/ping failures. My best suggestion is to look for external hardware issues (like a flakey Ethernet cable or PC Ethernet interface).
Offline
faizan wrote:
Hi,
Thanks for the reply.
Verify that both nodes are able to output the received dummy packets via Ethernet.
As per your suggestion I have tried to verify the received packets on the ethernet.
i have followed the set-up as : at Node 1 I have connected the board B1 ( problematic)
When the dummy packets are transmitted from node 1 to node 2 I get the result in wire shark as ' Unknown frame ( Bogus frame), kindly find the screen shot in http://twitpic.com/awt3l8
When the dummy packets are transmitted from node 2 to node 1 I get the result in wire shark as ' Ehernet frame checksum"
http://twitpic.com/awt40k
Kindly oblige.
Cant able to figure it out where my exact problem is. I have tried with arp -s, but nothing worked, as I am getting the same result before, not able to get ping response (ACK) from node connected to B1.
Can you help me out, how to resolve this error?
Offline
The effects you've described aren't consistent with one another. I can't think of a reason that pings wouldn't work through the reference design yet WARPLab and dummy packet mode work perfectly. Those two debugging steps showed that both Ethernet and your WARP radios work perfectly. Those are the only things that are needed for pinging to work.
So, it seems two me that one of two things is the happening:
A) You have some very intermittent problem that is only sometimes present. Murphpo mentioned a flaky PC Ethernet interface or Ethernet cable... those problems could manifest as what you are seeing.
B) Maybe you are mistaken about something you've told us? We've concluded based on what you've said that your radios and Ethernet work fine since you tested both of those in both directions (both Tx and Rx) for both WARP kits.
In either case, I think your next step should be to replace Ethernet cables and use a different PC and *carefully* reconstruct the experiments that led you to this point. Does dummy packet mode work in both directions on both boards? Does WARPLab work on both boards? Can your computers ping one another if they are directly connected over Ethernet? If the answer to all of those questions is 'yes,' than I can't imagine a scenario in which attempting to ping through NOMAC would fail.
Offline