[HamWAN PSDR] optimization first results

Bart Kus me at bartk.us
Sat Nov 2 09:14:47 PDT 2019

I would call these signal strengths "pretty good".

But don't take my word for it!  You can assess the quality yourself.  
"/ip neighbor print" will tell you exactly what hardware you're 
connected to.  In this case, both sides of the link are running 
RB912UAG-5HPnD modems.  The performance specs for these are at the 
bottom of the manufacturer's page:


MCS-7 is the highest order modulation & coding scheme supported on each 
chain.  What exactly is MCS-7?


You can see that's QAM-64 with 5/6 FEC overhead.  In order to use that 
highest speed, Mikrotik's spec page says it needs a signal of at least 
-75dBm.  Your most recent monitor snapshot here shows the weakest chain 
reporting -69dBm, so you're within spec to hit the highest supported speed.

HOWEVER, notice that Mikrotik's page also reports a drop in TX power as 
the modems move into MCS-7.  This is done to keep the transmitted signal 
from clipping / compressing, which allows it to be decoded correctly at 
the far end.  Your monitor snapshot here shows 3.2Mbit rate being used, 
which is equivalent to MCS-0.  (6.5Mbit @ 20MHz w/ 800ns GI == 3.2Mbit @ 
10MHz w/ 800ns GI)  The modems use the lowest link speed possible to 
support the data you're asking them to move, since this maximizes link 
reliability.  If you want, you can load up that link with some traffic, 
like from a bandwidth-test, and then as the modems hit MCS-7 per chain 
(MCS-15 overall due to MIMO), you should see it report something like 
72Mbit-10MHz/2S/SGI, and then you may observe different power numbers.

The 1S/2S notation here refers to the modem using 1 or 2 chains (streams).

The "SGI" refers to "Short Guard Interval", which is the same as the 
"400ns GI" listed on the Wikipedia page.  When not shown, the modems are 
using "800ns GI".  The real GI numbers are probably 1600ns and 800ns for 
the non-standard 10MHz mode, but I haven't measured NV2's signal in 
enough detail to confirm this.

You can also look at the CCQ numbers under load to see what percentage 
of frames are making the trip successfully on the 1st try.  The modems 
do automatic re-transmits if something is corrupted in flight.

I'm gonna stop now, since this email's far too long already for your 
simple question.  :)


On 11/2/2019 8:21 AM, Ric Merry wrote:
> Thank you Bart. I took all the step you suggested.
> Here are this mornings test results. If I was RF into a repeater I'd 
> be ecstatic about these signals, How is it in the HamWan world?
>   wireless-protocol: nv2
>                  tx-rate: 3.2Mbps-10MHz/1S
>                  rx-rate: 3.2Mbps-10MHz/1S
>                     ssid: HamWAN
>                    bssid: 74:4D:28:57:F6:BA
>               radio-name: Lookout-S2/WA7DEM
>          signal-strength: -64dBm
>      signal-strength-ch0: -66dBm
>      signal-strength-ch1: -68dBm
>       tx-signal-strength: -65dBm
>   tx-signal-strength-ch0: -69dBm
>   tx-signal-strength-ch1: -67dBm
>              noise-floor: -120dBm
>          signal-to-noise: 56dB
>                   tx-ccq: 6%
>                   rx-ccq: 6%
> On Fri, Nov 1, 2019 at 7:46 PM Bart Kus <me at bartk.us 
> <mailto:me at bartk.us>> wrote:
>     So, fun fact: you can still use Winbox even if you disable the
>     "/ip service winbox" service.  :)
>     Winbox is available as both an IP-routable service (/ip service
>     winbox), AND as an Ethernet-MAC-level service (/tool mac-server
>     mac-winbox).  Disabling the IP one still leaves the MAC one
>     accessible, as long as you're on the same Ethernet segment as your
>     modem.  The trick with the GUI is to click the MAC address when
>     choosing your device, not the IP address.
>     It's not intuitive, so maybe this email helps folks out.
>     PS: winbox.exe is a huge security risk and we should probably stop
>     recommending it.  It apparently downloads DLLs from the (possibly
>     exploited) modem and runs them on your Windows machine, with all
>     your user permissions at its disposal.
>     --Bart
>     On 11/1/2019 7:34 PM, Ric Merry wrote:
>>     Thanks Bart! I I ran the client setup page verbatim and this was
>>     the results with the exception of Winbox and Port222. I wanted to
>>     stick with Winbox until I was finished with the initial setup.
>>     I just received a new computer this afternoon so will move the
>>     whole set up along with all Ham related programs over to it.
>>     On Fri, Nov 1, 2019 at 3:36 PM Bart Kus <me at bartk.us
>>     <mailto:me at bartk.us>> wrote:
>>         Yes, much better.  I also noticed a problem on the HamWAN
>>         side, where that sector was configured for only 5MHz service
>>         instead of our normal 10MHz.  I've changed the sector config,
>>         and you should be getting twice the bandwidth now.
>>         I tried to run a speed test, but noticed your
>>         bandwidth-server was still set to require authentication, so
>>         I've logged into your modem and turned that off:
>>         [eo at K7ITE-Lookout] > /tool bandwidth-server set authenticate=no
>>         I also noticed you still have an "admin" account. If it's not
>>         properly password protected, this may be dangerous now that
>>         your modem is on the Internet.  I have left it untouched.
>>         I also noticed you have the "winbox" service running.  This
>>         is also dangerous, as it's full of exploits.  I have left it
>>         untouched, but you should probably disable it.  (/ip service
>>         disable winbox) We should update the website instructions to
>>         disable this by default.
>>         I also noticed your ssh is on port 22.  This will get more
>>         hacking attempts than port 222.  You can change it with /ip
>>         service set ssh port=222.
>>         With the bandwidth-server available on your end, I ran a
>>         speed test from the sector to your modem:
>>         [eo at Lookout-S2] > /tool bandwidth-test
>>         duration=30s direction=transmit
>>                         status: running
>>                       duration: 29s
>>                     tx-current: 38.4Mbps
>>           tx-10-second-average: 35.6Mbps
>>               tx-total-average: 37.5Mbps
>>                    random-data: no
>>                      direction: transmit
>>                        tx-size: 1500
>>               connection-count: 20
>>                 local-cpu-load: 20%
>>                remote-cpu-load: 28%
>>         [eo at Lookout-S2] > /tool bandwidth-test
>>         duration=30s direction=receive
>>                         status: running
>>                       duration: 29s
>>                     rx-current: 40.8Mbps
>>           rx-10-second-average: 41.7Mbps
>>               rx-total-average: 35.7Mbps
>>                   lost-packets: 1285
>>                    random-data: no
>>                      direction: receive
>>                        rx-size: 1500
>>               connection-count: 20
>>                 local-cpu-load: 21%
>>                remote-cpu-load: 27%
>>         This is the performance you can expect from a 10MHz MIMO link
>>         that has good signal.
>>         The current-distance is reported in km, not miles. It's not
>>         round-trip distance, just physical distance between the
>>         modems.  There is a separate metric for round-trip-time,
>>         which is measured in microseconds: tdma-timing-offset=202. 
>>         You can do the speed-of-light math to get a more precise
>>         distance than the 1km granularity reported by the
>>         "current-distance" field.
>>         --Bart
>>         On 11/1/2019 3:18 PM, Ric Merry wrote:
>>>         tx-rate: 6.5Mbps-5MHz/2S
>>>                          rx-rate: 3.2Mbps-5MHz/1S
>>>                             ssid: HamWAN
>>>                            bssid: 74:4D:28:57:F6:BA
>>>                       radio-name: Lookout-S2/WA7DEM
>>>                  signal-strength: -62dBm
>>>              signal-strength-ch0: -64dBm
>>>              signal-strength-ch1: -66dBm
>>>               tx-signal-strength: -62dBm
>>>           tx-signal-strength-ch0: -66dBm
>>>           tx-signal-strength-ch1: -64dBm
>>>                      noise-floor: -124dBm
>>>                  signal-to-noise: 62dB
>>>                           tx-ccq: 35%
>>>                           rx-ccq: 19%
>>>            authenticated-clients: 1
>>>                 current-distance: 32
>>>         Mo' betta? Is current distance miles in both send and
>>>         receive (round trip)?
>>>         On Fri, Nov 1, 2019 at 3:06 PM Bart Kus <me at bartk.us
>>>         <mailto:me at bartk.us>> wrote:
>>>             No, you're missing an entire chain of the radio (ch1). 
>>>             Do this to enable both chains:
>>>             /interface wireless set 0 rx-chains=0,1 tx-chains=0,1
>>>             --Bart
>>>             On 11/1/2019 2:55 PM, Ric Merry wrote:
>>>>             I climbed back up the ladder to do some fine tuning
>>>>             (thanks for the advice here)
>>>>             Luckily I could remotely view my computer with my cell
>>>>             phone thus saving me the cost of a divorce attorney had
>>>>             I asked my wife to help me when she gets home from work.
>>>>             ;)
>>>>             These are my results, I can do more but for now, how do
>>>>             they look?
>>>>             signal-strength: -66dBm
>>>>                  signal-strength-ch0: -66dBm
>>>>                   tx-signal-strength: -67dBm
>>>>               tx-signal-strength-ch0: -67dBm
>>>>               tx-signal-strength-ch1: -89dBm
>>>>                          noise-floor: -123dBm
>>>>                      signal-to-noise: 57dB
>>>>                               tx-ccq: 88%
>>>>                               rx-ccq: 70%
>>>>                authenticated-clients: 1
>>>>                     current-distance: 32
>>>>             Funny things is that thee are about where I started.
>>>>             Elevation is the more difficult adjustment with the
>>>>             brackets provided. I may end up modifying those.
>>>>             _______________________________________________
>>>>             PSDR mailing list
>>>>             PSDR at hamwan.org  <mailto:PSDR at hamwan.org>
>>>>             http://mail.hamwan.net/mailman/listinfo/psdr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20191102/00984b5f/attachment.html>

More information about the PSDR mailing list