[MVMA] Omni Scans

Chuck Gelm nc8q-mesh at gelm.net
Fri Jun 1 07:09:33 EDT 2018



On 05/31/2018 09:24 AM, Maurice Riggins wrote:
> Thursday morning, May 31st 2018, I did a wifi scan at each of our 
> dozen on-air 2.4 GHz
> Omnis, except for KA8ZKR Phil’s, to which I couldn’t link. It was only 
> heard at -88 db at
> XWARN omni and -92 db at WA8APB omni. Except for the latter, these are 
> our major host nodes
> for linking client nodes to the mesh. Here are the results, ordered 
> more or less east to west.Including client nodes served, the largest 
> number of other nodes heard above noise at any of
> omnis this morning is ten (10). We still need to replace the node at 
> KAS and put a filter
> on the node at Vandalia.
>
> Note the client nodes at N8ADO, W8GUC, N8JJ, and AB8XA aren't heard by 
> any omnis except the
> one that links them to the mesh. Also note the AirRouter HP at N8ADO 
> isn't heard by any omnis,
> including nearby KAS. It's only received above noise by the N8ADO NSM2.
>
Of these MVMA 2.4 GHz stations, I think:

If W8XRN is transmitting,
  W-XENIA, WA8APB, Xenia-South, N8NQH, KAS, N8NQH at N8DCP, W6CDR, W8BI, 
MVHS, will not transmit.

If W-XENIA is transmitting,
  W8XRN, XENIA-SOUTH, N8NQH, WA8APB, MVHS, N8NQH at N8DCP, W8BI, VANDALIA, 
KAS, W6CDR, will not transmit.

If Xenia-South is transmitting,
  W-XENIA, MVHS, N8NQH, WA8APB, N8NQH at N8DCP, W8XRN, KAS, will not transmit.

If N8NQH is transmitting,
  MVHS, KAS, W-XENIA, XENIA-SOUTH, WA8APB, W8XRN, N8NQH at N8DCP, will not 
transmit.

If WA8APB is transmitting,
  W-XENIA, W8XRN, KAS, XENIA-SOUTH, N8NQH, N8NQH at N8DCP, MVHS, W8BI, 
KA8ZKR, VANDALIA, will not transmit.

If W8BI is transmitting,
  W8GUC-HH, W6CDR, W-XENIA, VANDALIA, KAS, W8GUC-2, MVHS, WA8APB, 
XENIA-SOUTH, will not transmit.

If Omni at W6CDR is transmitting, VANDALIA, W8BI, KAS, W-XENIA, will not 
transmit.

If VANDALIA is transmitting, W6CDR will not transmit.

If N8NQH at N8DCP is transmitting,
  KAS, AB8XA, W-XENIA, N8JJ, XENIA-SOUTH, W8XRN, MVHS, will not transmit.

if KAS is transmitting,
  MVHS, N8NQH, N8ADO-NSM2, N8NQH at N8DCP, WA8APB, W6CDR, W8XRN, W-XENIA, 
XENIA-SOUTH, W8BI will not transmit.

If MVHS is transmitting,
  KAS, N8NQH, W-XENIA, XENIA-SOUTH, WA8APB, W8BI, N8NQH at N8DCP, W8XRN, 
KD8DGH,  will not transmit.
-----

I think:

  These high profile 2.4 GHz omni cell coverage areas overlap many high 
profile neighbor's cells.
As long as these cells overlap, there will be higher latency due to channel
contention and collisions. A cure is to isolate the 2.4 GHz cells so 
that they
do not overlap their neighbor cell's high-profile node's area, then link 
the cells
via 3/5 GHz backbone/trunk links.

Some ways to isolate the LANs and 'force' interLAN traffic onto 
backbone/trunk channels are:
  Use antenna patterns that do not hear neighbor cells. e.g. 
Sector/panel instead of Omni.
  Lower high profile (Neighborhood class) antennas so they do not hear 
neighbor cells.
  Use different channels/bands.
  Use different bandwidths. (1)

(1) This may not reduce contention in neighboring cells, but it will 
help reduce hops > 2 on 2.4 GHz .
By 'hops' I mean 'node to node' relayed data on the same channel.
In a recent test comparing latency from a node terminal not on 2.4 GHz 
to a node service reachable by not on 2.4 GHz,
Of 4 tests
  3 had 2 hops (on 2.4 GHz) with an average latency of ~600 milliseconds.
  1 had 4 hops (none on 2.4 GHz) with an average latency of ~6.5 
milliseconds.

Perhaps we should do more to encourage the routing of interLAN data via 
backbone/trunk nodes.

Maybe,

Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qth.net/pipermail/mvma/attachments/20180601/3661a9d3/attachment.html>


More information about the MVMA mailing list