[HamWAN PSDR] The 3rd time is not charmed [was: 8dB drop/rise!]
Bart Kus
me at bartk.us
Mon Jul 21 11:24:13 PDT 2014
Have you looked at the possibility that your modem is negotiating a
higher link speed over time and that's the cause for the gradual signal
level loss? When you reboot these things and they aren't pressed to
move data, they opt for the slowest (and highest power) modulation. As
data comes in for them to move, if they build up queues, they try higher
order modulations, which make use of amplitude modulation, and reduce
the average power level.
It is possible to instruct the modem to only support a subset of
speeds. For example, the slowest speed only (6Mbit):
[eo at AE7SJ/Monroe-Paine] /interface wireless> set 0 supported-rates-a/g=
12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps 6Mbps 9Mbps
I don't think upgrading or downgrading firmware has anything to do with
RSSI readings as they're read directly from the Atheros chip and not
computed in firmware.
The real test of the health of your connection would be if it
consistently supports the same ballpark speed range (bits/sec actually
moved) or if it is indeed dropping due to this 8dB RSSI delta you're
seeing. If the modem finds itself having too many communication errors
because it chose a modulation that is too fast, it'll lower its
negotiated speed.
--Bart
On 7/21/2014 10:28 AM, Dean Gibson AE7Q wrote:
> OK, over the last three weeks both the TX and RX signal levels have
> dropped 8dB; see:
>
> http://www.ae7q.com/misc/media/5.9GHz/2014-07-xx.png
>
> While this could be due to vegetation, the drop (somewhat gradual this
> time) looks suspiciously like the previous two drops of 8dB (see prior
> messages below). On Friday I noticed that MicroTik had a new firmware
> release, v6.17, and I upgraded to that. That fixed an NTP bug
> introduced in v6.14 but made no difference in dBm levels, so Sunday
> evening I downgraded to v6.13. That downgrade/reboot was successful,
> but also made no difference. So, I did a second reboot in preparation
> for upgrading back to v6.17 (using the same scenario as below).
>
> This time, however, "presto!" (the results below) does not quite
> apply. The 5SHPn shows a power-on LED, and when connected to a
> switch, shows an electrical network LED. However, *the 5SHPn is
> inaccessible via Ethernet* (using Winbox to access via both by last IP
> address, and by MAC address). PINGs fail; there is no corresponding
> entry in the ARP table. I can hold in the reset button while
> power-cycling the 5SHPn, and I get the flashing power LED indicating a
> "reset configuration" is happening, but to no avail: Winbox is unable
> to connect to the 5SHPn.
>
> *This is the third time I've had this 8dB drop*, and the second time
> I've had to go to the roof to reset the radio. So, I've removed the
> antenna from the roof. So, unless someone has a bright idea, the
> 5SHPn and the 31dBi dish antenna are available for $120 total. I'd
> like to sell them as a unit, because I've got a really nice (but
> easily removable) taped seal of the antenna/radio connection. If you
> can't get the radio to work, you're only out $20.
>
> -- Dean
> 425-338-4276 (home)
> 425-359-4276 (cell)
>
> On 2014-06-13 18:29, Dean Gibson AE7Q wrote:
>> Going back to v6.13 didn't improve anything, but it did seem to get
>> rid of the occasional variations in voltage (from 13.5v down to
>> 12.8v) that SNMP was reporting to "The Dude" software. So, after
>> letting v6.13 run for couple hours with no improvement, I reinstalled
>> v6.15.
>>
>> Presto! Instant dBm improvement back to my normally observed
>> values. Here are links to SNMP graphs of the drop @9:30am, and the
>> rise at 17:48pm. Of course, you can also see this in Nigel's Cacti
>> reporting, albeit with less horizontal (time) resolution.
>>
>> http://www.ae7q.com/misc/media/5.9GHz/2014-06-13_0940.png
>> http://www.ae7q.com/misc/media/5.9GHz/2014-06-13_1740.png
>>
>> Note that the reported sudden dBm "rise" to -60dBm (the upper limit
>> I've imposed to keep the graph scale reasonable) on two occasions in
>> the second graph, is when I upgraded and then reconfigured the radio
>> (from a cut-&-paste script), and should be ignored.
>>
>> Note that a very similar scenario occurred several months ago, when I
>> upgraded from v6.10 to v6.12.
>>
>> Of course, today is Friday the 13th. Maybe Jason is responsible.
>>
>> -- Dean
>>
>> On 2014-06-13 12:28, Dean Gibson AE7Q wrote:
>>>
>>> On 2014-06-13 12:13, Cory (NQ1E) wrote:
>>>> Did it rain on those trees you're pointing at around then? :)
>>>>
>>>> On Fri, Jun 13, 2014 at 12:12 PM, Dean Gibson AE7Q <hamwan at ae7q.com
>>>> <mailto:hamwan at ae7q.com>> wrote:
>>>>
>>>> This morning (well after the update to v6.15 last night) just
>>>> after 9:30am, I saw a 8dB drop in both TX and RX signal levels,
>>>> which persist at this time. I did a "reset configuration",
>>>> which did not solve the problem.
>>>>
>>>> Did anyone do a change at Paine sector 2 around 9:30am?
>>>>
>>>
>>> It's been raining gently all morning. Last night it rained a bit
>>> harder, and I saw no significant or unusual variation. I'm going
>>> back to v6.13 to see if that changes anything.
>>>
>>> The drop was very sudden. I have that antenna connection very well
>>> sealed, I thought, and the Ethernet cable runs uphill to get into
>>> the eaves. I did a cursory visual check of that this morning.
>>
>
> On 2014-05-04 13:00, Dean Gibson AE7Q wrote:
>> OK, everything is back working, and I have my dBm back!!
>>
>> Not a comedy of errors, but two factors intertwined to create this
>> problem:
>>
>> 1. Since configuring the radio after a configuration reset requires
>> the use of WinBox (until you get IP addresses set up), I moved
>> the network connection from the radio to its normal router on the
>> DMZ, and connected it to a router on my LAN via an extension
>> Ethernet cable and a "dual-RJ-45-jack adapter". The port light
>> on the router associated with the radio connection was off. This
>> morning when I went to disconnect the cables, I saw the port
>> light on the router flash momentarily. Junked the dual-RJ-45
>> adapter and used another one (I had previously tried a different
>> cable), and I had WinBox access to the radio! Everything worked
>> except for the LEDs ...
>> 2. *After much more screwing around*, I found out that for version
>> 6.12,*the LEDs are not configured by default* !!! Remember, I
>> had done a "reset-configuration" ...
>>
>>
>> So, for others that update to v6.12, here are the relevant lines in
>> the setup:
>>
>> */system leds add type=interface-status interface=ether1-local
>> leds=user-led
>> /system leds add type=wireless-signal-strength
>> interface=wlan1-gateway leds=led1,led2,led3,led4,led5*
>>
>> Now that I know I can configure the LEDs with other options, I'll try
>> some.
>>
>> I have no clue as to why my dBm dropped, and why I now have my prior
>> values back ...
>>
>> -- Dean
>>
>>
>> -----Original Message-----
>> From: PSDR [mailto:psdr-bounces at hamwan.org
>> <mailto:psdr-bounces at hamwan.org>] On Behalf Of Dean Gibson AE7Q
>> Sent: Sunday, May 4, 2014 1:44 AM
>> To: Puget Sound Data Ring
>> Subject: Re: [HamWAN PSDR] Metal 5SHPn firmware 6.12 is current
>> (addendum)
>>
>> Well, this did not end well. ... I decided to reset the
>> configuration (using the command line) ... it appears to have
>> "bricked" the radio.
>>
>> It draws about 160ma (about the value from a week ago, when I
>> first measured it). There is no light on the side of the unit,
>> and the Ethernet port is dead.
>>
>>
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140721/9b65c52d/attachment.html>
More information about the PSDR
mailing list