Question about Radio Mobile link

Radio Mobile is not a perfect science and people use it in various ways.  This is how I use it.

I always model for MCS0 and then look to see what else I might get.  Here are the parameters I use:
 

I use .25 watts Tx Power.  While it's spec'd at .5 watts, that get's split between the vertical and horizontal domains; I use .5 dB loss in both Rx and Tx paths lines due to the coax jumpers; and I use 4 μV receive threshold because that's approximately equivalent to the MCS0 sensitivity of -94 dB.  You didn't specify the antennas you plan to use... and the 26 dB Rocket Dish or 18 dB sector antenna are candidates.  Those values get plugged into their respective fields.

When Radio Mobile comes back with its link analysis, it will calculate a Fade Margin.  From, my personal experience (and the values I've used, above), I know I need about 15 dB of margin for a basic connection.  Anything above will only increase the MCS rate for me.  For example.  I see that MCS15 requires 19 dB more received signal (94-75); I also see that the Rocket transmit power is 5 dB lower at that same rate... so I need a total of 24 dB (19+5) more fade margin... 39 dB in total (24+15) to achieve that data rate.

39 dB of Fade Margin is a lot, and I don't often achieve that (or MCS15 for that matter) on a link.

I hope this helps as a start.  Your own experiences will likely change the way you use Radio Mobile.  I started by modeling and then going out and seeing what results I got on the modeled links.  Eventually I established this baseline and it's worked out pretty well for me.  I have found that the UBNT airLink tool to be less than helpful.

Andre, K6AH
 

If you telnet into the node, the following command will indicate the MCS rate the device is running:

Here's an example of a node I have in my backyard pointing to a regional AREDN backbone node around 26 miles away,  The Node Status screen indicates -73 / -95 / 22 dB S/N/R.

type         rate     throughput  ewma prob   this prob  retry   this succ/attempt   success    attempts
HT20/LGI     MCS0            5.6      100.0       100.0      1              0(  0)         1           1
HT20/LGI     MCS1           10.5      100.0       100.0      4              0(  0)         4           4
HT20/LGI     MCS2           14.8      100.0       100.0      5              0(  0)        93          93
HT20/LGI     MCS3           18.6       97.7       100.0      5              0(  0)      1380        1416
HT20/LGI  tP MCS4           25.1       99.9       100.0      5              0(  0)     31688       33264
HT20/LGI     MCS5            8.6       25.8       100.0      0              0(  0)       175        3495
HT20/LGI     MCS6            0.0        0.0         0.0      0              0(  0)         1        3495
HT20/LGI     MCS7            0.0        0.0         0.0      0              0(  0)         0        3495
HT20/LGI     MCS8           10.5      100.0       100.0      0              0(  0)         1           1
HT20/LGI     MCS9           18.6       99.9       100.0      5              0(  0)       368         380
HT20/LGI     MCS10          25.1       99.9       100.0      5              0(  0)     37921       38776
HT20/LGI T   MCS11          30.3       99.9       100.0      5              0(  0)    439091      448760
HT20/LGI     MCS12          14.1       33.2       100.0      6              0(  0)      4482        8447
HT20/LGI     MCS13           0.0        0.0         0.0      0              0(  0)         0        3495
HT20/LGI     MCS14           0.0        0.0         0.0      0              0(  0)         0        3496
HT20/LGI     MCS15           0.0        0.0         0.0      0              0(  0)         0        3495

The "T" in the 10th character position indicates the current MCS rate, and a "t" indicates the current fallback rate.  In this case the link is running MCS11 at 30.3 Mbps.

Note that the command returns this chart for each of its connections.

Andre, K6AH

With apologies to Joyce Kilmer

Strictly-speaking it is not all attenuation - some of it is forward-scattering that messes up the coherence of wave fronts so that they do not add up properly at the receiver. So it looks like attenuation, but does not behave exactly like an attenuator.  One big tree can have more attenuation than you expect; a forest can have less attenuation that you might calculate. Leaves and twigs that are 1/2 wavelength long have the biggest impact.

The problem with RadioMobile is that it really underestimates the effect of passing through trees, or tree tops. It also does not know what your path really looks like in terms of ground cover and obstacles. It is probably the wrong tool for propagation through trees, but you can try to increase the "density" number in Options/Elevation data to match your field test results. First look at the point-to-point path (tools/radio link - view profile) and see what objects the land cover file thinks are in the path (you might be surprised). Then adjust the height and density of those objects (options/elevation data).  The highest density I think you can use is 1000%.  Someone in the RadioMobile user group tried to make trees match the actual measured 3 GHz results and needed a density number > 1000%. So that may not be the answer.

There is a hidden feature to use an alternative attenuation model in RadioMobile.  You need to edit the "landheight.dat" file. For example:

​ 0, 0
 15, 100
 25, 60
 15, 100
 15, 60
 15, 70
 10, 70
 5, 10
 1, 10
 1, 10
 1, 5
 1, 5
 0, 0
 10, 100
 15, 115
2,0.2,0.5,0.8

The first set of numbers comes from the GUI.  The last one is a line *you* add, saying to use model #2 with parameters 0.2/0.5/0.8 (in this example). 
This is the CCIR 236-2 model (Google is your friend).The parameters are k, x and y, respectively.
If you add this line, the numbers will appear in the GUI as shown in the attached JPG.
Note: this model then applies to ALL the objects in the land cover file, not just trees.

I would like to calibrate this model against field measurements of attenuation due to ground clutter (aka trees) versus height, but nobody has given me a quad copter yet ;-)

With the numbers shown (and not based on anything in particular) I see results that seem to me a lot closer to reality; i.e., only very short paths work in leafy areas. 
 

It is fundamental that 0.6 Fresnel clearance MUST clear tree tops. Not as black and white at 900 Mhz, but nearly so with 900 being slightly more forgiving. This clearance is a must for 2.4 GHz and up. I have made 100s of microwave paths. Ham radio can cut a lot of corners versus any equivalent commercial system design for lower frequencies and modes, but not when it comes to 2.4 GHz and above. Unless, you are ok with the frustration and links that work some of the year.

If there is a rise or a ridge in the terrain shown on the path profile that is within 20 meters (per airLink) of 0.6 Fresnel in the path, drive to the area and make a physical survey. APRS is very helpful in locating yourself with the areas of interest. Also, the Boy Scout Handbook taught us how to estimate tree heights ... although I never understood why they needed to know. There might be building. It might be a bare ridge and not a problem. Or, as I found once in PA, an enormous coal mine slag pile in the way that the field survey did not initially recognize!

I think airLink is a fantastic tool with instant results, but some help from the real world is necessary.

-Jeff W9NIZ