You are not logged in.
Pages: 1
Hello,
With your assistance, I've been trying to implement dual-radio design in WARP. I have added another microblaze CPU, as well as cores like mac_hw, phy_tx, phy_rx. Another set of tx/rx buffers are also added to the design. Now that there are two cpu_lows, cpu_high decides which cpu_low it will use to send the next packet. If cpu_high decides to send its next packet to cpu_low_2, it stores the packet in the 2nd tx buffer and sends an ipc message to cpu_low_2. In the rx path, phy_rx receives signals from RFA where
as phy_rx_2 receives signals from RFB.
I can describe all my details, but since it is a long story, I want to share the problem I'm facing now and get your opinion on this.
First of all, the modification is quite successful when using nomac. With original reference design, the throughput_two_nodes.py shows one-way throughput of approximately 40Mbps when NONHT is used and MCS=7 (54Mbps configuration). With the new design, when RFA is tuned to ch. 36 and RFB is tuned to ch. 48, I get one-way throughput of 80Mbps.
The problem occurs when I use DCF instead of nomac. With original design (single-channel configuration), one-way throughput is 28-29Mbps. When I use dual-radio (ch. 36 and 48), I only get 32-33Mbps.
With some debugging, I found out that the "delay_done" (delay for sending one frame) is much larger when using dual-radio configuration. the delay seemed like the two RFs are competing for the channel (which I don't understand because they are on different channels.)
So what I did is I tried increasing the cca_thresh from -62 to -32, just to see if RFA was finding the channel busy when RFB is transmitting. Result is, the throughput actually increases (I've seen up to 46Mbps), but also there are lots of errors in packet RX (indicated by fast changing of 4 red LEDs.) There is hardly any external signal on 5GHz channels in the building I'm working, so I don't think packet losses are caused from external interference.
So are signals on channel 36 and 48 really interfering each other? I don't think that makes sense, but I can't think of other explanations or other means of testing to find out the problem cause.
Offline
First of all, congratulations getting that architecture designed and built; that can't have been easy. That's very cool.
Regarding the performance of DCF vs. NOMAC, here are a couple of follow-up questions.
1. Do you still see the CCA intermingling between the interfaces if you cross the 2.4GHz and 5GHz bands (e.g. channel 1 on MAC A and channel 36 on MAC B)?
2. Do you have a UART hooked up to either CPU_LOW cores? Do you ever see the "found in %d iterations" during the steady state operation (it happens at boot while CPU_HIGH is taking its time to boot up)? One difference between NOMAC and DCF is the CPU_HIGH has more stuff it needs to do when CPU_LOW is the DCF. For example, CPU_HIGH will create log entries for each retransmission that occurs as well as log entries for control frames like ACKs. It doesn't explain the CCA observations, but one explanation for lower throughput with DCF is that CPU_HIGH isn't able to keep up with two backlogged low-level MACs. That print would occur if there is any merit to this theory. It would mean that one or both of your low-level MACs is unable to grab an Rx packet buffer to receive into because they are waiting on CPU_HIGH to clear one. If this is the problem, we can speed up CPU_HIGH by disabling logging and/or counts updates, but there isn't any point in going down this road unless you have some evidence that you are limited by CPU_HIGH processing time.
3. How did you handle the 3 MPDU packet buffer structure in this architecture? How does wlan_mac_high_is_dequeue_allowed() work now that you have two low-level MACs? Is it possible that, while MAC A is deferring in the DCF, CPU_HIGH is unable to start transmission in MAC B?
Offline
I tried assigning channel 6 to RFA and channel 48 to RFB, and now I'm starting to think I did something wrong in decoupling RFA and RFB. Before describing experiment results, I will answer number 2 and 3 first.
2. I have connected uart to CPU_LOW_2, this "Searching for empty packet buff ... found in X iterations" message does not show while running. It is printed once at boot time, and there is no other message printed out from CPU_LOW_2.
3. In function poll_tx_queues(), the original code has the if block that starts by calling wlan_mac_high_is_dequeue_allowed(). Inside, the function checks the status of TX buffers by accessing them through TX_PKT_BUF_TO_ADDR(i).
I added another tx buffer in the design (rx buffer too), and I replicated the if block in poll_tx_queues() which would start by calling wlan_mac_high_is_dequeue_allowed_2(). This function will look for empty buffers in the second tx buffer by accessing them through TX_PKT_BUF_2_TO_ADDR(i).
CPU_LOW will only use TX_PKT_BUF_TO_ADDR while CPU_LOW_2 will only use TX_PKT_BUF_2_TO_ADDR. I carefully checked to make sure they don't access each other's packet buffer, which would cause disaster.
poll_tx_queues is called whenever CPU_LOW or CPU_LOW_2 signals CPU_HIGH that a transmission has been finished.
The last statement remains, "Is it possible that, while MAC A is deferring in the DCF, CPU_HIGH is unable to start transmission in MAC B?"
I did experiments to see if that is true, which I will describe next.
1. I did 3 experiments.
Experiment #1.
Dual-radio, DCF, Channel 6 and 48. Each node distributes packets to CPU_LOW (RFA) and CPU_LOW_2 (RFB).
Result:
Testing Node 1 -> Node 2 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 30.25 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Testing Node 2 -> Node 1 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 32.27 Mbps
Testing Head-to-Head throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 16.14 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 15.27 Mbps
Comment:
Single channel throughput (DCF) of channel 6 is about 20Mbps, while single channel throughput of channel 48 is 29Mbps. Channel 6 is has lots of beacons/probes flying around so the throughput is lower than 5GHz channels. (Channel 1 and 11 are even worse.)
So.. better than 29Mbps but I'd expect to get something like 50Mbps...
Experiment #2.
Dual-radio, DCF, Channel 6 and 48. Node 1 only sends packets to CPU_LOW and Node 2 only sends packets to CPU_LOW_2. So in this case, if node 1->2 is X Mbps and node 2->1 is Y Mbps, the head-to-head throughput should be just Node 1->2: X and node 2->1: Y, I'd expect. But...
Testing Node 1 -> Node 2 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 19.01 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Testing Node 2 -> Node 1 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 29.31 Mbps
Testing Head-to-Head throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 1.65 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 28.71 Mbps
Comment: What's happening in head-to-head throughput? Are they *contending* for the channel? It seems like node 2 is mostly finding the channel idle, while node 1 is not transmitting because its finding the channel busy? Am I using input from RFB to determine channel status of RFA?
One thing to note is that I checked with spectrum analyzer that when RFA and RFB are assigned to channels 1 and 6 respectively, they actually send out packets on that respective channel. (It is also obvious that if they don't do that, I can't get 80Mbps.)
Experiment #3:
Dual-radio, nomac, Channel 6 and 48. Node 1 only sends packets to CPU_LOW and Node 2 only sends packets to CPU_LOW_2.
This experiment is done to see if RFA on channel 6 is interfered by signals from channel 48. The result seems that it is not.
Testing Node 1 -> Node 2 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 36.40 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Testing Node 2 -> Node 1 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 41.74 Mbps
Testing Head-to-Head throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 37.44 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 37.31 Mbps
From experiment 2, I think it is not just a problem of two RFs in the same node interrupting each other, because in that experiment each node is just using one cpu_low to transmit.
Offline
I have an update on the 4 red LEDs when running experiment #2.
When doing node 2 -> node 1, in which node 2 is sending packet through RFB, the red LEDs move but they move slowly.
But when doing head-to-head throughput the red LEDs move much faster, indicating high packet loss. So it may not be a problem of CCA but packet losses.
So to summarize:
node 1 and node 2 both tune RFA to channel 6 and RFB to channel 48.
When node 2 sends packets to node 1 through channel 48, not a lot of packet losses occur and we get 29Mbps throughput (which is expected).
When node 2 sends packets to node 1 through channel 48 and node 1 sends packets to node 2 through channel 6, many packets received at node 1 are found to be FCS_BAD (indicated by LEDs).
Offline
Very interesting... I need to think about these observations more.
A few questions:
-Does your design have 1 or 2 instances of the radio_controller core? If 1 instance, did you disconnect the 'usr_any_PHYStart' port and use the 'usr_RFA_PHYStart'/'usr_RFB_PHYStart' ports instead?
-In your NoMAC tests are the transmissions all using the same packet size? throughput_two_nodes.py uses 1400-byte payloads for both streams by default. What happens with NoMAC and different packet sizes on each stream (i.e. 1400-byte n1->n2, 400-byte n2->n1). We would expect slightly lower throughput with smaller packets due to increased overhead. I'm curious if there's a larger-than-expected difference.
Offline
I will try using different packet sizes with NoMAC and post the results.
Here I will first answer the first question.
1. I am using 1 radio_controller core, and I did exactly like you said regarding the PHYStart ports. I thought I was stuck there, but fortunately found out the ports were actually separated by reading the HDL source file (great relief).
Here is a part of my system.mhs file. I renamed some of them to recognize which ones are connected to the first RF (wlan_phy_tx, wlan_phy_rx, wlan_agc) and which ones are connected to the second RF (wlan_phy_tx_2, wlan_phy_rx_2, wlan_agc_2).
# Inter-core ports for hardware radio control
# PORT usr_any_PHYStart = tx_phy_start
PORT usr_RFA_PHYStart = tx_phy_start
PORT usr_RFB_PHYStart = tx_phy_start_2
PORT usr_RFA_TxEn = phy_rc_txen_a
PORT usr_RFA_RxEn = rc_usr_rxen
PORT usr_RFA_RxHP = agc_rfa_rxhp
PORT usr_RFA_RxGainBB = agc_rfa_g_bb
PORT usr_RFA_RxGainRF = agc_rfa_g_rf
PORT usr_RFA_TxGain = phy_rc_tx_gain_a
PORT usr_RFB_TxEn = phy_rc_txen_b
PORT usr_RFB_RxEn = rc_usr_rxen_2
PORT usr_RFB_RxHP = agc_rfb_rxhp_2
PORT usr_RFB_RxGainBB = agc_rfb_g_bb_2
PORT usr_RFB_RxGainRF = agc_rfb_g_rf_2
PORT usr_RFB_TxGain = phy_rc_tx_gain_b
Also, here is the wlan_phy_rx_2 core part (connected to CPU_LOW_2). I've commented out five input ports regarding RFA here, without knowing its consequence. (What happens when there is nothing connected to input port of a core?)
I thought it was okay because wlan_phy_rx_2 will be configured to use RFB.
BEGIN wlan_phy_rx_pmd_axiw
PARAMETER INSTANCE = wlan_phy_rx_2
PARAMETER HW_VER = 4.00.w
PARAMETER C_INTERCONNECT_S_AXI_AW_REGISTER = 7
PARAMETER C_INTERCONNECT_S_AXI_AR_REGISTER = 7
PARAMETER C_INTERCONNECT_S_AXI_W_REGISTER = 7
PARAMETER C_INTERCONNECT_S_AXI_R_REGISTER = 7
PARAMETER C_INTERCONNECT_S_AXI_B_REGISTER = 7
PARAMETER C_BASEADDR = 0x45000000
PARAMETER C_HIGHADDR = 0x4500FFFF
BUS_INTERFACE S_AXI = mb_low_2_axi_periph
BUS_INTERFACE PORTB = WLAN_RX_PKT_BUF_2_PORTB
PORT axi_aclk = clk_160MHz
PORT sysgen_clk = clk_160MHz
# PORT pkt_det_in = net_wlan_phy_rx_pkt_det_in
PORT pkt_det_in = net_gnd
PORT rx_sigs_invalid = rx_sigs_invalid_2
PORT rx_iq_samp_ce = agc_iq_valid_out_2
# PORT rfa_rx_i = agc_rfa_i_2
# PORT rfa_rx_q = agc_rfa_q_2
# PORT rfa_rssi = RFA_RSSI_D_REG
PORT rfb_rx_i = agc_rfb_i_2
PORT rfb_rx_q = agc_rfb_q_2
PORT rfb_rssi = RFB_RSSI_D_REG
PORT rssi_adc_clk = wlan_rssi_clk
PORT pkt_det_o = phy_rx_pkt_det_2
# PORT rfa_g_rf = agc_rfa_g_rf_2
# PORT rfa_g_bb = agc_rfa_g_bb_2
PORT rfb_g_rf = agc_rfb_g_rf_2
PORT rfb_g_bb = agc_rfb_g_bb_2
PORT agc_done = agc_done_2
# MAC <-> PHY ports
PORT phy_rx_reset = phy_rx_reset_2
PORT phy_rx_block_pktdet = phy_rx_block_pktdet_2
PORT phy_cca_ind_busy = mac_phy_cca_ind_busy_2
PORT phy_rx_data_byte = mac_phy_rx_data_byte_2
PORT phy_rx_data_bytenum = mac_phy_rx_data_bytenum_2
PORT phy_rx_data_done_ind = mac_phy_rx_data_done_ind_2
PORT phy_rx_data_ind = mac_phy_rx_data_ind_2
PORT phy_rx_end_ind = mac_phy_rx_end_ind_2
PORT phy_rx_end_rxerror = mac_phy_rx_end_rxerror_2
PORT phy_rx_fcs_good_ind = mac_phy_rx_fcs_good_ind_2
PORT phy_rx_phy_hdr_ind = mac_phy_rx_phy_hdr_ind_2
PORT phy_rx_phy_hdr_length = mac_phy_rx_phy_hdr_length_2
PORT phy_rx_phy_hdr_mcs = mac_phy_rx_phy_hdr_mcs_2
PORT phy_rx_phy_hdr_phy_mode = mac_phy_rx_phy_hdr_phy_mode_2
PORT phy_rx_phy_hdr_unsupported = mac_phy_rx_phy_hdr_unsupported_2
PORT phy_rx_start_ind = mac_phy_rx_start_ind_2
PORT phy_rx_start_phy_sel = phy_rx_start_phy_sel_2
END
Offline
I have done the experiments.
In this experiment, I used nomac, and each node uses both RFs to send packets.
Node 1 sends 1400-byte packets while node 2 sends 400-byte packets.
Here is the result.
UPDATE: CHANNELS USED: 36 and 48. 2.4GHz channels are quite crowded here and produce unexpected results.
Testing Node 1 -> Node 2 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 82.05 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Testing Node 2 -> Node 1 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 35.34 Mbps
Testing Head-to-Head throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 10.87 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
The throughput decreased from 82.05 to 35.34. I've ran the experiments at least five times
and the results are almost the same numbers.
Now for comparison, I also ran single-channel experiments with original reference design. Node 1 uses 1400-byte packets, while node 2 uses 400-byte packets.
The result:
Testing Node 1 -> Node 2 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 41.51 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Testing Node 2 -> Node 1 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 26.65 Mbps
Testing Head-to-Head throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
From the single-channel result, I guess we'd expect the dual-radio result with 400-byte packets would be somewhere around 52, but we are getting lower throughput. What would be the meaning behind this?
One observation: when doing nomac testing with dual-radio, depending on the antenna position I get different results. If I put the two antennas straight up, I get roughly 70Mbps. When I make the two antenna spread out like V shape, I get around 80Mbps of throughput. The result I've posted here is from this antenna positioning.
Now about the nomac throughput: When we use 54Mbps rate, we get around 41Mbps of throughput (when there is no external interference). Each packet transmission takes 273us (confirmed from printing average delay_done value, and also consistent with 41Mbps of throughput).
Since nomac does not do backoff and there is no ACK, I was thinking the only overhead was preamble transmission which takes 20us. The transmission time of payload is 11200 bits / 54Mbps = 207.4us. So what is the additional overhead which takes approximately 45-46us?
Last edited by Kevin20 (2016-May-24 21:54:04)
Offline
I don't want to post too much text, but I have to report this.
Everything here is done using dual-band and DCF. Traffic is distributed among RFA and RFB.
Here are the observations so far.
1. If I use the same spectrum band for RFA and RFB (e.g. RFA: ch. 36 and RFB: ch. 44), I get a one-way throughput of 31-32Mbps by using two radios, which is slightly larger than single-channel throughput. This result is almost consistent regardless of antenna and device positions.
2. If I use different spectrum band for RFA and RFB (e.g. RFA: ch. 6 and RFB: ch. 44), this is the BEST result I've got so far.
Testing Node 1 -> Node 2 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 46.96 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Testing Node 2 -> Node 1 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 46.86 Mbps
Testing Head-to-Head throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 23.92 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 25.50 Mbps
Single channel throughput of channel 44 is 29Mbps, whereas single channel throughput of channel 6 is 18-19Mbps, so here we are actually achieving the expected throughput. (sum of the two)
The problem is: when I use this configuration the result is too sensitive to how I position the devices and the antennas. If I rotate the devices and move the antennas up and down left and right, I get different results. Usually I get around 25-30Mbps, which is again similar to the single-channel throughput.
Offline
First, I would strongly recommend replacing your antennas with attenuators+cables to remove any dependance on the wireless environment (propagation channel, interference, etc). Always use at least 30dB attenuation between Tx and Rx interfaces. I usually test 802.11 PHY stuff with >50dB attenuation for more realistic Rx powers.
The suggestion of using different packet lengths was hoping to induce different behaviors in the two interfaces at one node. One theory is that one RF interface transitioning between Tx/Rx somehow interferes with the waveform at the other interface. Try a throughput experiment where one interface sense 1400-byte packets and the other sends 400-byte packets. This will cause one interface to be transmitting while the other cycles through Tx/Standby/Rx/Standby/Tx.
It's clear there's some interaction between the DCF instances that we can't isolate. I think you need to dig deeper than you can with throughput tests. A few experiment ideas:
-Start with one AP node, terminate both its RF ports and disable beacons (n_ap.configure_bss(None) from Python). Then configure the node with a low-rate LTG flow to the broadcast address transmitting only from RF A. Monitor the MAC state at RF B - does the MAC state depend on the Tx state RF A at all? For example, if you probe the debug header "Idle for DIFS" signal for RF B, does it ever go to 0 (i.e. does MAC B think the medium is busy)? You can monitor debug header signals with an oscilloscope. Alternatively you can poll the CCA_BUSY bit in the wlan_mac_hw STATUS register.
-In the same experiment does the idle Rx PHY show any Rx activity (RX_STARTED events, good/bad FCS, etc)?
-Does your custom design support the wlan_exp logging infrastructure? This is all implemented in CPU High, so I suspect it still works. The Tx/Rx logs might provide lots of useful insight here. For example, you could look at Tx events in the dual-interface/dual-flow experiment and see how many re-transmissions were required by each interface. This would help clarify why the dual-DCF/dual-flow throughputs (1.65 vs 28.71 Mbps) were so different. Were there many re-transmissions for the 1.65 Mbps (indicating lots packet losses at Rx)? Or just not very many transmissions (indicating lots of deferrals to a busy-medium by the Tx).
Offline
For another data point, do you think you could try your DCF vs. NOMAC experiments again but with the lowest MCS of 6Mbps? If the presence of the second MAC/PHY interface caused a small EVM degradation on the first MAC/PHY interface, then the 54Mbps rate you used would be most susceptible. Since each interface has its own unique characteristics and sensitivity (due to unavoidable hardware variance), it's conceivable that the degradation would manifest asymmetrically. For example, XdB of degradation on interface A might still be decodable at 54Mbps whereas the same XdB of degradation on interface B might push the SNR regime over the BER waterfall. I'm curious if the 1.65 Mbps vs. 26.81 Mbps asymmetry goes away with a more conservative rate selection.
I think the MAX2829 datasheet lends some credence to this theory. Look at the "OFDM EVM WITH OFDM JAMMER vs. OFDM JAMMER LEVEL WITH JAMMER OFFSET FREQUENCY" graph on page 16. The presence of a jammer that is 100MHz away, which is technically out of the same channel, produces a modest 4% EVM degradation when the jamming signal is received at -30dBm. In your scenario, your "jammer" can be tuned further away than 100MHz (which helps), but it also has an Rx power that is potentially louder than -30dBm depending on how close together your RFA and RFB antennas are on a single node. murphpo's suggestion of trying RF cabling + attenuation will also help provide some insight here.
Offline
I've come back with cables and attenuators. I'm using 50dB attenuation as suggested.
I am getting GOOD RESULTS as follows:
configuration: RF A (Ch. 36) + RF B (Ch. 48), both using DCF.
Run Experiment:
Testing Node 1 -> Node 2 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 57.71 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Testing Node 2 -> Node 1 throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 0.00 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 58.58 Mbps
Testing Head-to-Head throughput for rate 54.0 Mbps (NONHT 64-QAM 3/4) ...
Node 1 -> Node 2: Rate = 54.0 Mbps Throughput = 29.53 Mbps
Node 2 -> Node 1: Rate = 54.0 Mbps Throughput = 29.92 Mbps
So the theory of "interference from far-away frequency" is actually true..?
I will have to check the MAC behavior to see if activity on RF A is affecting MAC status of RF B, when I am using antennas.
Offline
I've come back with cables and attenuators. I'm using 50dB attenuation as suggested.
I am getting GOOD RESULTS as follows:
This is consistent with one antenna Tx activity causing degradation of the Rx signal at the other antenna. In a sense you're building a full-duplex system. It's nominally FDD, but without sharp filters to separate the channels responses, a Tx antenna will "jam" the Rx antenna. If things work reliably over cables, it suggests the isolation between RF A and B on the WARP v3 is sufficient for your scheme. This isolation is around 50dB. You should be able to achieve similar performance over-the-air if you achieve similar isolation between the antennas. Passive shielding, directional antennas, and inline filters are all options here.
Offline
I understand. But I have one question. How do the commercial dual-band routers achieve the isolation?
I used to experiment with routers like TP-Link WDR4300 which has two RFs on 2.4GHz and 5GHz. The router has three antennas, and the RF A on 2.4GHz supports 2x2 MIMO, whereas RF B on 5GHz supports up to 3x3 MIMO.
I only experimented with legacy mode (54Mbps rate), but there was no problem transmitting and receiving through the two RFs simultaneously. Is this because they are on different band?
I also attached a USB Wi-Fi configured to run on channel 11 (RF A is on channel 6), but the two interfaces seem to work fine as well.
Offline
We saw a similar issue: In a neighboring office, there was an SRD operated in the mid-5GHz band. Tuning a WARP device to the same channel, we had -50dBm reception power. However, if we used a channel that is separated by 100MHz, the signal was still detectable and decode-able (confirmed by matching decoded MAC addresses at the WARP node).
What we also saw was when tuning to a frequency that is not exactly an integer multiple of the bandwidth, we could operate at a much closer frequency separation.
Maybe for your internal testing purposes, if you don't have to be inter-operable with WiFi devices, you could try changing the carrier of one of the RF devices by a few MHz.
Otherwise, wouldn't it also help to separate the carriers of both RF interfaces (e.g. one in 2.4 and one in 5GHz)?
Offline
Kevin20 wrote:
I understand. But I have one question. How do the commercial dual-band routers achieve the isolation?
I used to experiment with routers like TP-Link WDR4300 which has two RFs on 2.4GHz and 5GHz. The router has three antennas, and the RF A on 2.4GHz supports 2x2 MIMO, whereas RF B on 5GHz supports up to 3x3 MIMO.
I only experimented with legacy mode (54Mbps rate), but there was no problem transmitting and receiving through the two RFs simultaneously. Is this because they are on different band?
I also attached a USB Wi-Fi configured to run on channel 11 (RF A is on channel 6), but the two interfaces seem to work fine as well.
I suspect the way that dual-band routers work is that they have really sharp filters that isolate the 2.4GHz and 5GHz bands. I did a little Googling and I think I found a simple bandpass filter that would help isolate your two interfaces. K&L Microwave has a neat filter wizard that lets you specify characteristics of a filter you want and then produces a link to the product that meets those specifications.
I think this filter part 5C50-5180/T20-OP/O could work for you. It's 3dB bandwidth is 20MHz centered at 5180 MHz (Channel 36). Once you get up to 5240MHz (Channel 48), this filter will suppress the signal is suppressed by more than 80 dB -- that should be enough for your Channel 36 + Channel 48 dual design to operate. It also appears you can order it with an SMA Male connector on one side and an SMA female connector on the other, so it can just sit in between the SMA port on the WARPv3 interface and your antenna.
Offline
Pages: 1