With a 8P8C modular banjo and a 5 1/2 digit bench DMM.... just part of the standard test equipment in the lab.
-forrest On Thu, Jan 21, 2016 at 5:58 AM, Josh Baird <joshba...@gmail.com> wrote: > Thanks for the info! I'm going to see if I can crank my 24V DC-DC > converter up to ~29V at this site temporarily. It's too snowy at the > moment to rewire for 48V. How were you determining voltage at the AP? > > On Thu, Jan 21, 2016 at 2:43 AM, Forrest Christian (List Account) < > li...@packetflux.com> wrote: > >> A bit of an update from the PacketFlux side. >> >> Late this afternoon I received a ticket from Tyson in relation to these >> issues. In particular, sync from a PacketFlux SyncInjector dropping off on >> an ePMP when it's cold. I have spent a bit of time this evening >> investigating this issue. The following is a summary of what I found. >> It's a bit long-winded so that those experiencing the problems can >> understand my current working theory and help me figure out if this is the >> case. >> >> WARNING: The following is based on a limited amount of testing with a >> single ePMP with no traffic and no clients and on a bench. This is likely >> the best case scenario. The field is only going to be worse. >> >> The setup is as follows: >> >> ePMP 1000 GPS AP, with no GPS hockey puck attached, connected to a >> Gigabit Syncinjector (Rev H and Rev I - I have a special one with a port of >> each 'type' ;-) ). I am powering the injector with a variable power >> supply so I can vary the voltages in. The AP is connected to the Injector >> with ~100m of CAT5 cable. The Antenna connectors have terminators on >> them, the AP is in transmit mode, but isn't passing any traffic since there >> are no clients. >> >> When feeding the injector with 24V, I get about 23V at the AP. This is >> pretty consistent with what I would expect in this situation. The AP >> seems to work fine, at least on the bench and without doing any real >> work. However, as the voltage drops, things start to get weird: >> >> At around 22V in, (21V at the AP), Sync becomes flaky. This is >> consistent on both H and I version ports on the injector. Sometimes it >> works, sometimes it doesn't. Note that 22V is the bottom of the rated >> voltage inputs for the ePMP. >> >> At around 20.5V in (19.5V at the AP), the radio just turns off. It >> won't turn back on until around 22V. >> >> Now here's where some total speculation comes to play. On the bench, >> this unit is drawing around 3W. Let's assume that under load, and when >> temperatures are cold, this unit draws closer to 6W. This would double the >> current, and quadruple the voltage drop. Now, assume 24V in, this puts you >> at around 20V in at the AP, which is about the turnoff point. Remember >> this is on 100m of wire, and a total speculation about a the power draw of >> a cold, under load AP. But the point is valid, regardless of the cause - >> if the circuit resistance when combined with the power load causes a low >> enough voltage at the AP, weird things will happen. And since weird things >> seem to start to happen around 22V, there just isn't much headroom at >> 24V. >> >> This explains why things work well at 30V. >> >> For those who are having this problem I'd recommend trying increasing the >> voltage into the SyncInjector. The Revision H injectors can safely handle >> up to around 56V or so. Assuming all of the radios on an injector are >> either ePMP or the newer 450i's, using 56V into a SyncInjector is perfectly >> acceptable and the ePMP's are rated up to 56V as well. >> >> So the summary: Try a 48VDC voltage source instead of 24V and see what >> happens. >> >> -forrest >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jan 20, 2016 at 11:00 AM, Tyson Burris @ Internet Communications >> Inc <t...@franklinisp.net> wrote: >> >>> Hello Cambium, >>> >>> >>> >>> At the MidWest-IX launch party last night, several of us Indiana WISPs >>> compared notes on the ‘cold weather’ problems we are seeing with ePMPs. It >>> was very interesting to learn we are experience identical problems across >>> the spectrum. >>> >>> We all understand this is a DRAM issue with certain units you have >>> identified. We also understand the firmware RC that has been made >>> available to fix this short term. >>> >>> The bottom line is we are very frustrated and grow tired of dealing with >>> it. >>> >>> >>> >>> Our concern is simple. If your software fix ‘degrades’ the performance >>> of the product or triggers other issues, as it has been suggested, we would >>> prefer a full recall and replacement program immediately. >>> >>> >>> >>> If the suggestion that the fix will degrade the product performance is >>> inaccurate and not cause other issues, I would like for this to be made >>> public. >>> >>> >>> >>> Thank you, >>> >>> >>> >>> *Tyson Burris, President* >>> *Internet Communications Inc.* >>> *739 Commerce Dr.* >>> *Franklin, IN 46131* >>> >>> *317-738-0320 <317-738-0320> Daytime #* >>> *317-412-1540 <317-412-1540> Cell/Direct #* >>> *Online: **www.surfici.net* <http://www.surfici.net> >>> >>> >>> >>> [image: ICI] >>> >>> *What can ICI do for you?* >>> >>> >>> *Broadband Wireless - PtP/PtMP Solutions - WiMax - Mesh Wifi/Hotzones - >>> IP Security - Fiber - Tower - Infrastructure.* >>> >>> *CONFIDENTIALITY NOTICE: This e-mail is intended for the* >>> *addressee shown. It contains information that is* >>> *confidential and protected from disclosure. Any review,* >>> *dissemination or use of this transmission or its contents by* >>> *unauthorized organizations or individuals is strictly* >>> *prohibited.* >>> >>> >>> >> >> >> >> -- >> *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* >> Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 >> forre...@imach.com | 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 forre...@imach.com | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>