For initial installs, I typically have exactly the opposite experience. Probably because when I actually do the system design it isn't a problem since I use trusted power supplies which I carefully oversize. This creates a bit of a blind spot for me. Because I only got involved in this case after the radio was installed and not working (couldn't enable XPIC) I wasn't aware that staff had used a substandard power supply *on both ends*. We're going to have to do a bit of training about power supply sizing apparently.
In-the field failures? Usually the power supply. On Sat, Feb 17, 2018 at 11:04 PM, Bill Prince <[email protected]> wrote: > In all fairness... I have been in various technical positions for the last > 40+ years. The frequency of power as the source of the problem, whatever it > may be, is more than pretty much any other cause. > > Always. Always. Always. Check the power. > > > bp > <part15sbs{at}gmail{dot}com> > > > On 2/17/2018 9:03 PM, Forrest Christian (List Account) wrote: > > Hey, thanks everyone for the suggestions about the power supply. I'm > really not sure why that didn't occur to me since I've been bitten by that > in the past, and it's pretty common for me to ask customers the exact same > question. I'm going to blame it on insufficent sleep and working on it way > too late. > > The problem did turn out to be an issue with an undersized power supply > preventing the radio from powering on after both radios got enabled. They > swapped the ones they had with a stronger one in the form factor they're > dealing with (DIN mount), and the radios powered right up. > > > > On Sat, Feb 17, 2018 at 1:38 PM, Forrest Christian (List Account) < > [email protected]> wrote: > >> What is funny is that they swapped the crap 24V din rail 1.7A thing they >> had for a packetflux supplied 48V power supply and it seems to be working. >> >> Thanks for everyone for the pointers and reminding me of what I already >> knew. Part of the issue here is that I haven't physically touched these >> radios or seen the electrical config, and am relying on staff at the WISP. >> Someone missed the whole wattage thing, and in fairness to staff, the 820c >> 'assured installation' manual is less than forthcoming about the power >> supply requirements, so unless you know to go look for the radio wattage, >> this is something easily missed. >> >> On Sat, Feb 17, 2018 at 1:15 PM, Bill Prince <[email protected]> wrote: >> >>> I may have just fallen off the turnip truck, but I know this company >>> called Packetflux that makes a thing called a SiteMonitor that you could >>> use to monitor the input voltage and current if you were so inclined. >>> >>> >>> bp >>> <part15sbs{at}gmail{dot}com> >>> >>> >>> On 2/17/2018 11:52 AM, Forrest Christian (List Account) wrote: >>> >>> Ok, clarification, this still might be a power issue, checking on >>> this... >>> >>> >>> On Sat, Feb 17, 2018 at 12:25 PM, Forrest Christian (List Account) < >>> [email protected]> wrote: >>> >>>> I'm awake again. Apparently these are the stock 820c ac power >>>> supplies. >>>> >>>> >>>> On Feb 17, 2018 11:32 AM, "Roland Houin" <[email protected]> wrote: >>>> >>>>> Agree, could be inadequate power. >>>>> when activating the second core, it takes more power.. >>>>> we have tried using sync injectors, work with 1 core, too much load >>>>> for 2nd core. >>>>> >>>>> Roland >>>>> >>>>> >>>>> > Sounds like a watchdog timer or a power supply overheating and >>>>> folding. >>>>> >>>>> From: Bill Prince >>>>> Sent: Saturday, February 17, 2018 8:41 AM >>>>> To: [email protected] >>>>> Subject: Re: [AFMUG] PTP820C radios not booting up - ideas? >>>>> >>>>> If I'm reading this right, it worked at some point where you could >>>>> configure it? >>>>> This implies that something is wonky in your configuration. If you >>>>> have it >>>>> connected to a Mikrotik, you could scan for IPs and/or MAC addresses >>>>> to see if >>>>> it somehow is changing its IP or something. >>>>> >>>>> Is someone onsite to check, or is this all happening remotely? >>>>> >>>>> bp >>>>> <part15sbs{at}gmail{dot}com> >>>>> >>>>> On 2/17/2018 3:19 AM, Forrest Christian (List Account) wrote: >>>>> >>>>> So we have a new (i.e. put into production in the last couple of days) >>>>> pair of >>>>> 820C radios. I discovered earlier tonight that XPIC was not enabled on >>>>> the >>>>> radios, limiting throughput. >>>>> >>>>> In the process of enabling XPIC, we made some changes to the config, >>>>> rebooted >>>>> both ends, and now neither end will boot fully. We see the interfaces >>>>> come up >>>>> for about 30 seconds every 2.5 minutes, then they drop off and the >>>>> cycle >>>>> repeats. >>>>> >>>>> We've tried power cycling both ends. We've tried powering off one end >>>>> in hopes >>>>> it was related to the radios talking to each other. >>>>> >>>>> We have also attempted to get in with the 'splitter cable' on the >>>>> management >>>>> port. Using the provided IP addresses, we get a few pings out of the >>>>> radio each >>>>> cycle on the 'recovery port' (like 4), but are not able to start a web >>>>> session >>>>> at all. I haven't put a packet sniffer on it to see if it responds to >>>>> the SYN >>>>> packet or not, but it sure doesn't seem like it even starts a >>>>> connection (just >>>>> times out). >>>>> >>>>> In the hopes that SNMP was coming up during this time and I could >>>>> issue a config >>>>> reset via SNMP, we also tried to do a SNMP put and a SNMP get (at >>>>> different >>>>> times) with the community string we configured the radios with, and it >>>>> seems >>>>> like SNMP is not responding either. >>>>> >>>>> I'm going to get some sleep now, and try again tomorrow. We've opened >>>>> up a >>>>> ticket with Cambium support but I'm not getting any meaningful >>>>> response out of >>>>> them, and because of the timing, they're unable or unwilling to >>>>> escalate beyond >>>>> level one. >>>>> >>>>> I'm hoping someone has been through this and knows the magic >>>>> solution.... Any >>>>> ideas? >>>>> >>>>> -- >>>>> >>>>> Forrest Christian CEO, PacketFlux Technologies, Inc. >>>>> >>>>> Tel: 406-449-3345 <%28406%29%20449-3345> | Address: 3577 Countryside >>>>> Road, Helena, MT 59602 >>>>> <https://maps.google.com/?q=3577+Countryside+Road,+Helena,+MT+59602&entry=gmail&source=g> >>>>> [email protected] | http://www.packetflux.com >>>>> >>>>> < >>>>> >>>>> >>>>> >>> >>> >>> -- >>> *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* >>> Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 >>> <https://maps.google.com/?q=3577+Countryside+Road,+Helena,+MT+59602&entry=gmail&source=g> >>> [email protected] | http://www.packetflux.com >>> <http://www.linkedin.com/in/fwchristian> >>> <http://facebook.com/packetflux> <http://twitter.com/@packetflux> >>> >>> >>> >> >> >> -- >> *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* >> Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 >> <https://maps.google.com/?q=3577+Countryside+Road,+Helena,+MT+59602&entry=gmail&source=g> >> [email protected] | http://www.packetflux.com >> <http://www.linkedin.com/in/fwchristian> >> <http://facebook.com/packetflux> <http://twitter.com/@packetflux> >> >> > > > -- > *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* > Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 > <https://maps.google.com/?q=3577+Countryside+Road,+Helena,+MT+59602&entry=gmail&source=g> > [email protected] | http://www.packetflux.com > <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> > <http://twitter.com/@packetflux> > > > -- *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 [email protected] | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
