[HamWAN PSDR] How to Aim Uplink on a Tower
Doug Kingston
dpk at randomnotes.org
Sat Feb 1 14:08:12 PST 2020
The existing interfaces have no tone feature. I am suggesting an app that
could poll the OID and give a tone mapped to the value would be nice. You
would need to be able to set the Host, Credentials, OID, value range to
tone range mapping, and possibly polling frequency, but it would need to be
sub-second to be useful.
On Sat, Feb 1, 2020 at 1:23 PM Herb Weiner <herbw at wiskit.com> wrote:
> Thanks, Doug. Are you suggesting that tone feedback would be a useful
> feature (I agree), or is there already some way to enable tone feedback?
>
> Herb
>
> On Feb 1, 2020, at 12:38 PM, Doug Kingston <dpk at randomnotes.org> wrote:
>
> I really like the idea of a tone feedback.
>
> On Sat, Feb 1, 2020 at 10:20 AM Herb Weiner <herbw at wiskit.com> wrote:
>
>> Thanks, Tom. I was not aware of the print oid command, bu t this looks
>> very promising. We certainly will practice this.
>>
>> Herb
>>
>> On Feb 1, 2020, at 10:02 AM, Tom Hayward <tom at tomh.us> wrote:
>>
>> I have never heard of Aim Master.
>>
>> The Mikrotik command to learn OIDs is "print oid". Example:
>> [tom at Baldi.Crystal] /interface wireless> print oid
>> 0 tx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.2.2 rx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.3.2
>> strength=.1.3.6.1.4.1.14988.1.1.1.1.1.4.2 ssid=
>> .1.3.6.1.4.1.14988.1.1.1.1.1.5.2
>> bssid=.1.3.6.1.4.1.14988.1.1.1.1.1.6.2 frequency=.1.3.6.1.4.1.14988.1.1.1.1.1.7.2
>> band=.1.3.6.1.4.1.14988.1.1.1.1.1.8.2
>> [tom at Baldi.Crystal] /interface wireless> registration-table print oid
>> 0 signal-strength=.1.3.6.1.4.1.14988.1.1.1.2.1.3.212.202.109.98.213.93.2
>> tx-signal-strength=
>> .1.3.6.1.4.1.14988.1.1.1.2.1.19.212.202.109.98.213.93.2
>> tx-bytes=.1.3.6.1.4.1.14988.1.1.1.2.1.4.212.202.109.98.213.93.2
>> rx-bytes=.1.3.6.1.4.1.14988.1.1.1.2.1.5.212.202.109.98.213.93.2
>> tx-packets=.1.3.6.1.4.1.14988.1.1.1.2.1.6.212.202.109.98.213.93.2
>> rx-packets=.1.3.6.1.4.1.14988.1.1.1.2.1.7.212.202.109.98.213.93.2
>> tx-rate=.1.3.6.1.4.1.14988.1.1.1.2.1.8.212.202.109.98.213.93.2 rx-rate=
>> .1.3.6.1.4.1.14988.1.1.1.2.1.9.212.202.109.98.213.93.2
>> routeros-version=.1.3.6.1.4.1.14988.1.1.1.2.1.10.212.202.109.98.213.93.2
>> uptime=.1.3.6.1.4.1.14988.1.1.1.2.1.11.212.202.109.98.213.93.2
>> signal-to-noise=.1.3.6.1.4.1.14988.1.1.1.2.1.12.212.202.109.98.213.93.2
>> tx-signal-strength-ch0=
>> .1.3.6.1.4.1.14988.1.1.1.2.1.13.212.202.109.98.213.93.2
>> signal-strength-ch0=.1.3.6.1.4.1.14988.1.1.1.2.1.14.212.202.109.98.213.93.2
>> tx-signal-strength-ch1=
>> .1.3.6.1.4.1.14988.1.1.1.2.1.15.212.202.109.98.213.93.2
>> signal-strength-ch1=.1.3.6.1.4.1.14988.1.1.1.2.1.16.212.202.109.98.213.93.2
>> tx-signal-strength-ch2=
>> .1.3.6.1.4.1.14988.1.1.1.2.1.17.212.202.109.98.213.93.2
>> signal-strength-ch2=
>> .1.3.6.1.4.1.14988.1.1.1.2.1.18.212.202.109.98.213.93.2
>>
>> Once you have found enough signal to maintain a connection, exit out of
>> scan and use mon for much better data. It will show you both chains.
>> [tom at haystack.evergreenmonroe] > /in wi mon 0
>> status: connected-to-ess
>> channel: 5880/10/an
>> wireless-protocol: nv2
>> tx-rate: 43.3Mbps-10MHz/2S/SGI
>> rx-rate: 52Mbps-10MHz/2S
>> ssid: HamWAN
>> bssid: 6C:3B:6B:5D:5E:17
>> radio-name: Haystack-S3/K7WAN
>> signal-strength: -67dBm
>> signal-strength-ch0: -69dBm
>> signal-strength-ch1: -71dBm
>> tx-signal-strength: -68dBm
>> tx-signal-strength-ch0: -71dBm
>> tx-signal-strength-ch1: -71dBm
>> noise-floor: -118dBm
>> signal-to-noise: 51dB
>> tx-ccq: 80%
>> rx-ccq: 79%
>> authenticated-clients: 1
>> current-distance: 22
>> wds-link: no
>> bridge: no
>> routeros-version: 6.46
>> last-ip: 192.241.235.209
>> current-tx-powers:
>> 6Mbps:27(27/30),9Mbps:27(27/30),12Mbps:27(27/30),18Mbps:27(27/30),24Mbps:27(27/30),36Mbps:27(27/30),48Mbps:25(25/28),54Mbps:24(24/27),HT20-0:27(27/30),HT20-1:27(27/30),
>>
>> HT20-2:27(27/30),HT20-3:27(27/30),HT20-4:27(27/30),HT20-5:27(27/30),HT20-6:25(25/28),HT20-7:23(23/26)
>> notify-external-fdb: no
>>
>>
>>
>> Practice on the ground if you've never done it before.
>>
>> Tom KD7LXL
>>
>> On Wed, Jan 29, 2020 at 5:52 PM Kenny Richards <richark at gmail.com> wrote:
>>
>>> I have not used the Aim Master, but I would be surprised if it isn't
>>> operating off the same data being provided by the scan. As someone who has
>>> done a fair amount of the tower work, you really don't want to have them
>>> trying to manage anything additionally like watching a display.(regardless
>>> of what display) That is why having the pre-defined interactions between
>>> the ground person (who can completely focus on the data) and the tower
>>> person is the best solution.
>>>
>>>
>>>
>>> On Wed, Jan 29, 2020 at 4:53 PM Herb Weiner <herbw at wiskit.com> wrote:
>>>
>>>> Thanks, Kenny. This is the same technique we have used (except without
>>>> the HTs) when we are setting up a dish on a tripod, but I was really hoping
>>>> that there was a better way. And it is quite possible that the tower
>>>> climber will have experience with this. At this point, we don't know who
>>>> the tower climber will be, since KOIN requires that we use climbers
>>>> approved by them.
>>>>
>>>> I agree that scan sucks. Also, for aiming, an analog display really
>>>> would work better than a digital display. That is why I was hoping that I
>>>> could get Aim Master to work. (If anyone can tell me what some suitable
>>>> SNMP OIDs for aiming an antenna, I will try to update Aim Master. Perhaps
>>>> this would be a better solution.)
>>>>
>>>> Herb
>>>>
>>>> On Jan 29, 2020, at 4:32 PM, Kenny Richards <richark at gmail.com> wrote:
>>>>
>>>> Herb,
>>>>
>>>> The approach which has always been used when I have been involved uses
>>>> the output of /interface wireless scan 0, but it really requires two
>>>> people.
>>>>
>>>> 1) person on tower preps the dish and does their best to aim it in the
>>>> right direction. They report to ground (usually via a HT) that they are
>>>> ready.
>>>> 2) person on ground that is logged into radio, issues the scan command.
>>>> 3) The ground person at this point is in control and should be doing
>>>> almost all the talking. (which is good, because the person the tower needs
>>>> both hands aiming the dish)
>>>> 4) ground person reads the signal level, whether they see a connection
>>>> or not, etc. They need todo this continually, because the person on the
>>>> tower is completely operating on what they are being told. This means you
>>>> keep swing in one direction until the ground person tells you to stop and
>>>> go back the other direction.
>>>> 5) remember that you will need to adjust horizontal and vertical
>>>> multiple times to fine tune the signal.
>>>> 6) also remember the scan sucks and will 'stop' updating when it looses
>>>> the signal.
>>>> 7) the tower person has to try and go as slow and steady as possible
>>>> when adjusting.
>>>>
>>>> If you are using a professional tower climber, get a set of FRS radios
>>>> or something to send up with them. I'd be surprised if the pro's haven't
>>>> done this general alignment before, but that is just a guess.
>>>>
>>>> Kenny
>>>>
>>>>
>>>>
>>>> On Wed, Jan 29, 2020 at 1:53 PM Herb Weiner <herbw at wiskit.com> wrote:
>>>>
>>>>> In the near future, Oregon HamWAN (http://www.oregonhamwan.org) will
>>>>> be deploying three sectors and an uplink (aimed at Larch Mountain) on the
>>>>> KOIN Tower in Southwest Portland.
>>>>>
>>>>> What is the best way to optimize the aiming of our uplink? I am
>>>>> familiar with the use of /interface wireless scan 0, but it is difficult to
>>>>> optimize the signal strength using the output of this command.
>>>>>
>>>>> Aim Master (https://github.com/HamWAN/aim) looked like a promising
>>>>> approach, but it appears as if this has not been updated since 2016, and it
>>>>> appears to use SNMP MIBs that are no longer supported by the current
>>>>> firmware.
>>>>>
>>>>> We need to provide instructions for a professional tower climber that
>>>>> will probably have limited, if any, experience with HamWAN.
>>>>>
>>>>> Thanks for your suggestions.
>>>>>
>>>>> Herb, AA7HW
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PSDR mailing list
>>>>> PSDR at hamwan.org
>>>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>>>
>>>> _______________________________________________
>>>> PSDR mailing list
>>>> PSDR at hamwan.org
>>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>>
>>>>
>>>> _______________________________________________
>>>> PSDR mailing list
>>>> PSDR at hamwan.org
>>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>>
>>> _______________________________________________
>>> PSDR mailing list
>>> PSDR at hamwan.org
>>> http://mail.hamwan.net/mailman/listinfo/psdr
>>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org
>> http://mail.hamwan.net/mailman/listinfo/psdr
>>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.net/mailman/listinfo/psdr
>
>
> _______________________________________________
> PSDR mailing list
> 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/20200201/e42d937a/attachment.html>
More information about the PSDR
mailing list