Troubleshooting External Antennas on Meraki Access Points

Solved
sc27racer
Conversationalist

Troubleshooting External Antennas on Meraki Access Points

I was troubleshooting an MR74 mesh array (one gateway and five repeaters) that was taken out by lightning and found that two seemingly damaged MRs came back online when I swapped antennas. So now I need to test all the units and their antennas to separate the fully functional from the damaged.  All six MX74 access points have both 5.0 and 2.4 GHz radios enabled, one bank of two ports is clearly labeled 5.0 GHz and the other bank, 2.4GHz, and on my test access point, both radios and all four antenna ports are verified working. So far, so good.

 

[1] I opened my.meraki.com and saw that my phone had connected to Channel 112 on Radio 2. Channel 112 is in the 5.0 GHz band, so I can easily cycle through all of my dual-band omnidirectional antennas in sets of two in the 5.0 GHz bank of antenna ports on the test unit, identifying sets that produce lower than average signal strength, and when I find one that is subnormal, remove each of the test pair in turn to determine if one or both of the dipole antennas are fried, so I know how many antennas to purchase.

 

[2] If I then disable 5.0 GHz on that test access point, it will force my phone to connect to the other radio (2.4 GHz), and I can then repeat the process for the other pair of antenna ports, and in the end, know for certain that I have eliminated every antenna that does not provide average or better performance on both bands.  Tedious, but again, so far so good.

 

Question #1: In thinking through the procedure in [2], above, I presumed that each dipole omni antenna contains separate arrays for 5.0 GHz and 2.4 GHz. If that is true, it is necessary to exhaustively test the antennas a second time for the 2.4GHz band, but if not, I think it would be sufficient to ascertain that both antenna ports are working, since in that case the antennas would all have been tested sufficiently in [1]. Can someone tell me if the dipole omni uses separate arrays for each band, or the same for both, so I know if I can eliminate the antenna-swapping portion of [2]?

 

MR42E and MR53E Use Case

 

Now let's look at the MR42E (three radios and five antenna ports) and MR53E (four radios and six antenna ports).  The MR42E (MR53E) has five (six) external antenna ports:

  • The ports labeled 2.4/5 is meant for client serving radios (there are three 2.4/5 ports on the MR42E, four on the MR53E)
  • The port labeled Scan is meant for scanning wireless channels
  • The port labeled IoT is meant for BLE applications

The antenna ports on the MR74 are hard-assigned to either 5.0 or 2.4, and are labeled accordingly. The 2.4/5 ports on the MR42E and MR53E are not labeled into separate banks for 5.0 GHz and 2.4 GHz. Moreover, while it is possible that the MR53E preserves the MR74's practice of using two of the four 2.4/5 ports for each band, I can't see how such a practice is possible using the MR42E's three available 2.4/5 ports. It would be nice to understand this better before I need it!

 

And that brings us to Question #2: Can anyone shed light on Meraki's antenna port band allocation scheme for the MR42E and MR53E, as it relates to the 2.4/5 ports?

1 Accepted Solution
MerakiDave
Meraki Employee
Meraki Employee

@sc27racer  On your MR74, yes, you have 2 dedicated 2.4GHz ports and 2 dedicated 5GHz ports, as it is a dual-band 2x2 access point.  On the MR84, as well as the MR42E and MR53E you mention (the MR84 is basically an MR53E in an outdoor IP67 chassis) all of the ports are dual band. 

 

In the AP there is a diplexer to separate signals into the 2.4 and 5GHz radio chains.  So your methodology above would work for example on MR74, doing separate 2.4 and 5GHz tests, even with a dual-band antenna, because the MR74 ports are band-specific.  On an MR84 for example, the ports are not band-specific, you would have two identical antennas (like 2 ANT-25 patches or 2 ANT-27 sectors) with the same orientation, because each antenna is sending 2x2 and 2 spatial streams for both 2.4 and 5GHz radios.

 

On an MR42E/53E for example, all ports are dual band (except the IoT port of course which is 2.4GHz at 0dBm for proximity-based BLE applications).  The 42E is 3x3:3 and the 84 and 53E are 4x4:4 so every port is dual-band (versus having a separate physical set of 4 antenna ports which would get ugly fast).  So like you said, in those cases, it'll be a little more challenging (extra steps) to tell if any specific antenna element got fried, because you may need to set power settings manually or turn off the 2.4GHz radio for example to do band-specific testing.

 

Sorry to hear about the lightning strike.  Hope that helps!

 

 

View solution in original post

5 Replies 5
MerakiDave
Meraki Employee
Meraki Employee

@sc27racer  On your MR74, yes, you have 2 dedicated 2.4GHz ports and 2 dedicated 5GHz ports, as it is a dual-band 2x2 access point.  On the MR84, as well as the MR42E and MR53E you mention (the MR84 is basically an MR53E in an outdoor IP67 chassis) all of the ports are dual band. 

 

In the AP there is a diplexer to separate signals into the 2.4 and 5GHz radio chains.  So your methodology above would work for example on MR74, doing separate 2.4 and 5GHz tests, even with a dual-band antenna, because the MR74 ports are band-specific.  On an MR84 for example, the ports are not band-specific, you would have two identical antennas (like 2 ANT-25 patches or 2 ANT-27 sectors) with the same orientation, because each antenna is sending 2x2 and 2 spatial streams for both 2.4 and 5GHz radios.

 

On an MR42E/53E for example, all ports are dual band (except the IoT port of course which is 2.4GHz at 0dBm for proximity-based BLE applications).  The 42E is 3x3:3 and the 84 and 53E are 4x4:4 so every port is dual-band (versus having a separate physical set of 4 antenna ports which would get ugly fast).  So like you said, in those cases, it'll be a little more challenging (extra steps) to tell if any specific antenna element got fried, because you may need to set power settings manually or turn off the 2.4GHz radio for example to do band-specific testing.

 

Sorry to hear about the lightning strike.  Hope that helps!

 

 

sc27racer
Conversationalist

Thanks, @MerakiDave for the quick response and details!

ChrisKemsley
Meraki Alumni (Retired)
Meraki Alumni (Retired)

I can't answer Question 1 - I believe it is a single 'array' for both 2.4/5Ghz. A quick call into support should be able to confirm the physical characteristics.

 

For Question 2: For both the 42E and the 53E both bands go out all 2.4/5 antenna ports - so a 42 is a 3x3:3 AP, thereby 3 external antenna ports would be required to support the two wifi bands with 3 spatial streams. Same logic behind the 52E which is 4x4:4 thus the four ports for 2.4/5. As each Meraki AP currently sold supports a four radio architecture - WiFi scanning / BLE - one port for each radio exists. This was done in the models to allow for differentiated coverage for scanning or BLE versus WiFi. i.e. Directional antenna used for the WiFi with omni for the BLE / Scanning - or visa versus depending on the use case. 

 

I'm not sure what else you mean by band allocation other than to say its not band separated like the outdoor. Aesthetically this would start to get crazy with 8x8 (If band separated 16 antennas sticking out) and use case for indoor doesn't support for sending 2.4 into a different area than 5 (typically).

sc27racer
Conversationalist

Thanks, @ChrisKemsley for helping me to understand how the unit decides which antenna to allocate to which data stream in the same band. Dave's earlier reply touched on that same question in his mention of the diplexer that separates signals into the 2.4 and 5GHz radio chains, but I had to read both comments before I finally understood the answer.

MerakiDave
Meraki Employee
Meraki Employee

Sounds good @sc27racer let us know if we can help further, good luck with the rest of the testing.

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels