8dB drop in ten minutes!
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?
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@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?
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
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@ae7q.com <mailto:hamwan@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.
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@ae7q.com <mailto:hamwan@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.
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@ae7q.com <mailto:hamwan@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@hamwan.org <mailto:psdr-bounces@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.
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@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@ae7q.com <mailto:hamwan@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@hamwan.org <mailto:psdr-bounces@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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
The displayed link speed was also dropping. See http://www.ae7q.com/misc/media/5.9GHz/2014-07-xx_Data.png On 2014-07-21 11:24, Bart Kus wrote:
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@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_RX.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@ae7q.com <mailto:hamwan@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@hamwan.org <mailto:psdr-bounces@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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Are you sure that's graphing link speed? How did it dip below 6Mbit? (MHz y-axis label?) The modems cannot operate slower than that in only-n mode. --Bart On 07/21/2014 01:08 PM, Dean Gibson AE7Q wrote:
The displayed link speed was also dropping. See http://www.ae7q.com/misc/media/5.9GHz/2014-07-xx_Data.png
On 2014-07-21 11:24, Bart Kus wrote:
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@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_RX.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@ae7q.com <mailto:hamwan@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@hamwan.org <mailto:psdr-bounces@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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Well, now that the radio is inoperative, I can't look at the /interface wireless monitor output, but the graph comes from "The Dude". You're probably correct in implying that the graph shows effective speed. I'm trying "NetInstall", with no luck so far. On 2014-07-21 13:14, Bart Kus wrote:
Are you sure that's graphing link speed? How did it dip below 6Mbit? (MHz y-axis label?) The modems cannot operate slower than that in only-n mode.
--Bart
On 07/21/2014 01:08 PM, Dean Gibson AE7Q wrote:
The displayed link speed was also dropping. See http://www.ae7q.com/misc/media/5.9GHz/2014-07-xx_Data.png
On 2014-07-21 11:24, Bart Kus wrote:
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@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_RX.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@ae7q.com <mailto:hamwan@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@hamwan.org <mailto:psdr-bounces@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@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On Mon, Jul 21, 2014 at 10:28 AM, Dean Gibson AE7Q <hamwan.stuff@ae7q.com> wrote:
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.
Here's some information about restoring a RouterBoard with NetInstall: http://wiki.mikrotik.com/wiki/Manual:Netinstall
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.
This is a great deal for anyone who needs a HamWAN client. Resurrecting the modem is probably a 10 minutes job, and these Poynting antennas are sold out everywhere. Tom KD7LXL
On 2014-07-21 11:26, Tom Hayward wrote:
Here's some information about restoring a RouterBoard with NetInstall: http://wiki.mikrotik.com/wiki/Manual:Netinstall
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. This is a great deal for anyone who needs a HamWAN client. Resurrecting the modem is probably a 10 minutes job, and these Poynting antennas are sold out everywhere.
Tom KD7LXL
Thanks for the info about NetInstall, but when I hold the reset button on the 5SHPn, it stops flashing after about 15 seconds, which according to the documentation is the supposed acknowledgment that it is going to search for NetInstall for a PXE boot. NetInstall has the PXE server enabled, but never sees the 5SHPn. Yes, $120 is a good deal for the package.
On 2014-07-21 16:06, Dean Gibson AE7Q wrote:
On 2014-07-21 11:26, Tom Hayward wrote:
This is a great deal for anyone who needs a HamWAN client. Resurrecting the modem is probably a 10 minutes job, and these Poynting antennas are sold out everywhere.
Tom KD7LXL
Thanks for the info about NetInstall, but when I hold the reset button on the 5SHPn, it stops flashing after about 15 seconds, which according to the documentation is the supposed acknowledgment that it is going to search for NetInstall for a PXE boot.
NetInstall has the PXE server enabled, but never sees the 5SHPn.
Yes, $120 is a good deal for the package.
Having not received any offers for my "great deal", I began to wonder why the 5SHPn clearly is decoding pressing the reset button (by its flashing pattern), but then not interrogating "NetInstall" for the PXE boot. So, I decided to read up on PXE boot (NOT on the MicroTik site). I discovered that the "normal" PXE protocol starts out using DHCP, but I was never seeing the result of a DHCP-assigned IP address (and of course no response to access via the MAC address). So, I decided to go look in my DHCP server logs. I saw (and expected) DHCPDISCOVER / DHCPOFFER sequences prior to the failure, but after the failure, I was surprised to see BOOTREQUEST / BOOTREPLY sequences (with the appropriate IP address!) when trying to PXE boot. BOOTREQUEST / BOOTREPLY sequences are part of the old BOOTP protocol (before DHCP was invented). According to Wikipedia, *PXE normally uses DHCP, but the 5SHPn is using the old BOOTP protocol for PXE*. Since DHCP servers normally respond (for compatibility purposes) to BOOTP requests as well as DHCP requests, it appeared that my DHCP server was responding to the 5SHPn before the MikroTik "NetInstall" could, and since the former was not configured to send the 5SHPn a boot file, nothing happened. So, I temporarily disabled my DHCP servers, and voila! NetInstall laboriously (meaning very slowly) installed a new copy of the firmware. I did my usual reconfiguration script, and I was up and running, albeit with the 8dB loss. The first two instances of the 8dB drop were rather sudden, but the latest drop occurred over a period of about two weeks, which made me suspect vegetation growth as well as a problem with the 5SHP. So, I decided to engage in another antenna aiming session, and that seems to have recovered about 5dB of the drop. Bart: "/interface wireless monitor 0" shows "band: 5ghz-n-5mhz". I presume that means I'm using a 5MHz link?
Yes, that does mean you're on a 5MHz link. The monitor will also tell you modulation rates. They're not the same for RX and TX. And neither are the signal strengths. You re-gained 5dB? Was there some slow-moving angular creep in your mast setup? --Bart On 07/23/2014 07:44 PM, Dean Gibson AE7Q wrote:
On 2014-07-21 16:06, Dean Gibson AE7Q wrote:
On 2014-07-21 11:26, Tom Hayward wrote:
This is a great deal for anyone who needs a HamWAN client. Resurrecting the modem is probably a 10 minutes job, and these Poynting antennas are sold out everywhere.
Tom KD7LXL
Thanks for the info about NetInstall, but when I hold the reset button on the 5SHPn, it stops flashing after about 15 seconds, which according to the documentation is the supposed acknowledgment that it is going to search for NetInstall for a PXE boot.
NetInstall has the PXE server enabled, but never sees the 5SHPn.
Yes, $120 is a good deal for the package.
Having not received any offers for my "great deal", I began to wonder why the 5SHPn clearly is decoding pressing the reset button (by its flashing pattern), but then not interrogating "NetInstall" for the PXE boot. So, I decided to read up on PXE boot (NOT on the MicroTik site).
I discovered that the "normal" PXE protocol starts out using DHCP, but I was never seeing the result of a DHCP-assigned IP address (and of course no response to access via the MAC address). So, I decided to go look in my DHCP server logs. I saw (and expected) DHCPDISCOVER / DHCPOFFER sequences prior to the failure, but after the failure, I was surprised to see BOOTREQUEST / BOOTREPLY sequences (with the appropriate IP address!) when trying to PXE boot. BOOTREQUEST / BOOTREPLY sequences are part of the old BOOTP protocol (before DHCP was invented).
According to Wikipedia, *PXE normally uses DHCP, but the 5SHPn is using the old BOOTP protocol for PXE*. Since DHCP servers normally respond (for compatibility purposes) to BOOTP requests as well as DHCP requests, it appeared that my DHCP server was responding to the 5SHPn before the MikroTik "NetInstall" could, and since the former was not configured to send the 5SHPn a boot file, nothing happened.
So, I temporarily disabled my DHCP servers, and voila! NetInstall laboriously (meaning very slowly) installed a new copy of the firmware. I did my usual reconfiguration script, and I was up and running, albeit with the 8dB loss.
The first two instances of the 8dB drop were rather sudden, but the latest drop occurred over a period of about two weeks, which made me suspect vegetation growth as well as a problem with the 5SHP. So, I decided to engage in another antenna aiming session, and that seems to have recovered about 5dB of the drop.
Bart: "/interface wireless monitor 0" shows "band: 5ghz-n-5mhz". I presume that means I'm using a 5MHz link?
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On 6/13/2014 12:12 PM, Dean Gibson AE7Q 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?
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Not me. And I just verified the sector is @ default power. 8dB is pretty much the range of swing I see from second to second sometimes. --Bart
participants (5)
-
Bart Kus -
Cory (NQ1E) -
Dean Gibson AE7Q -
Dean Gibson AE7Q -
Tom Hayward