Depends on the radio. The 450i needs to voltage to drop below 30V (from 48 or 56V), so still a pretty nasty drop. Others are worse.
On Tue, Nov 10, 2015 at 2:26 PM, Bill Prince <[email protected]> wrote: > Oh wow. A simple solution. > > In fact.... I bet Forrest could do something like that now. It would be > interesting to see how small the voltage drop would have to be for the AP > to actually recognize the pulse. > > bp > <part15sbs{at}gmail{dot}com> > > > On 11/10/2015 1:22 PM, Chuck McCown wrote: > > Motorola could have done us all a favor by just superimposing a 1 or 2 > volt drop on the power than totally interrupting it. Just put a 1 Hz > square wave at the top of the power. The total interruption and terribly > narrow pulse width has cause lots of issues over the years. > > *From:* Forrest Christian (List Account) <[email protected]> > *Sent:* Tuesday, November 10, 2015 2:11 PM > *To:* af <[email protected]> > *Subject:* Re: [AFMUG] SyncInjectors and PMP450i > > It's a bit more complicated than that.. > > Yes, the pulse is effectively fed through the syncinjector. The injector > doesn't (as an example) realign the pulse, or anything like that. It > does, however, control the length of the power interruption and is able to > simply ignore a pulse if it deems it too close to a previous pulse. If it > ignores one, it increments the 'ignored pulse' counter. That prevents a > string of pulses (potentially caused by an outside source) from creating a > situation where the radio isn't getting enough power due to there being > more pulses than needed. Generally, if a pulse occurs sooner than 0.5S > after a previous one it will ignore the pulse (pulses normally occur once > every second - no more, no less). > > > > > > On Tue, Nov 10, 2015 at 12:57 AM, George Skorup < <[email protected]> > [email protected]> wrote: > >> Is the pulse from the pipe effectively fed directly into the radio ports >> and the SyncInjector just monitors it? Or does the SyncInjector reference >> the pipe's output and regenerates before output to the radios? I know the >> radios don't really care about a lost pulse here and there. IIRC, it's like >> 5 seconds before they declare it lost. >> >> If it's not this then I'm completely lost. Just odd that this seems to be >> happening on the towers with the longest runs (240-290 feet). But I'm far >> from blaming the SyncInjectors and/or SyncPipes. >> >> I really do believe this is some Canopy bug. I have the on-board GPS >> disabled on most of them that are exhibiting this issue. The last time, I >> went in and turned them back on and the on-board pulse was flip-flopping >> every second or two just like the power port. Cambium can't reproduce it >> yet as far as I know. And this really seemed to start happening when we got >> AutoSync. I've even seen this happen on single sectors with their own >> parasitic pipe as well (no power port timing, and with the on-board enabled >> and disabled). So I'm not sure if the on-board is causing this, but you'd >> think if it was disabled, then it should not be possible, but disabling it >> doesn't actually turn the receiver off. And like I said, it seems to happen >> around sundown which tells me it's either a temperature thing or a GPS Rx >> issue, plus all of the on-board receivers are aimed at the horizon through >> tower steel. And I have other receivers on the same sites to time FSK >> radios and they don't have any problems, just timing ports from deluxe's >> and parasitics, no other SyncInjectors though. >> >> I set up a cron script on an NTPd sync'd server to poll the 'used pulses' >> counter every hour and output it to a file. We'll see what that says. >> >> On 11/10/2015 12:38 AM, Forrest Christian (List Account) wrote: >> >> This problem isn't likely to affect all of the radios randomly at the >> same time. Since each port is driven by a separate set of electronics, >> and you have a separate cable to each radio, any effect should be >> radio-specific. >> >> I just looked at the syncinjector firmware - it needs 3-4 lost pulses >> before it declares the sync to be lost. I'm planning on tightening this >> up a bit to better catch errors like these, but I've got a couple of other >> critical items I'm working on before I can get there. >> >> Have you by chance looked at the increments of the sync pulses through a >> 24 hour period? In exactly 24 hours, there should be exactly 86,400 sync >> pulses used - no more no less. If you compare this to a atomic-synced >> clock you should be able to get fairly accurate counts. I.e. read that >> counter exactly at the top of an hour, and then look exactly 24 hours >> later. Be aware of non-accurate clocks though - my computer drifts a few >> seconds a day, if I don't sync it regularly (like a couple of times an >> hour). >> >> -forrest >> >> On Mon, Nov 9, 2015 at 4:58 PM, George Skorup < <[email protected]> >> [email protected]> wrote: >> >>> OK, now I'm very interested. I have multiple sites with regular 10/100 >>> SyncInjectors with 450 APs on them (no need for GigE). They're all on 200 >>> feet or more cable. Randomly, all APs at a site will show loss of power >>> port sync. More often, they say the sync pulse is flip flopping on and off. >>> Sometimes a reboot or a power-cycle will fix it, but mostly just have to >>> wait a few minutes for it to clear. This seems to happen right around >>> sundown most times. I was thinking that the on-board GPS starts freaking >>> out and triggers some AutoSync bug (which I know exists). I've pulled out >>> all surge suppressors, swapped SyncInjectors, SyncPIpes, nothing. And when >>> this happens, the SyncInjector status says the timing is fine, no events, >>> every time. >>> >>> But maybe this is actually my problem?? It has been very very rare on >>> shorter runs (like <150 feet). >>> >>> On 11/9/2015 5:20 PM, Forrest Christian (List Account) wrote: >>> >>> Sort of. >>> >>> First of all, a normal pulse out of a syncinjector into a short cable: >>> >>> [image: Inline image 5] >>> >>> >>> Interesting things happen when you shoot this into a long cable: >>> >>> [image: Inline image 1] >>> >>> Those bounces at the front are my best guess as to what is causing the >>> 450i to not like the sync pulse. That's on a 100m cable, and those pulses >>> are most likely caused by the signal bouncing off the end of the cable and >>> back and/or some different interaction with a long CAT5 cable. It should >>> be noted that similar bounces also happen with the 100 and the 450, and >>> even with official cambium sync sources (aka the CMM Micro), but the >>> software in those radios seem to ignore the stray pulses, only paying >>> attention to the final edge. Not so with the 450i. It just refuses to >>> play. >>> >>> The new I0 injectors turn the power off a bit more smoothly, making the >>> bounce not exist, even on a long cable: >>> >>> [image: Inline image 4] >>> >>> >>> On Mon, Nov 9, 2015 at 4:02 PM, George Skorup < <[email protected]> >>> [email protected]> wrote: >>> >>>> Let me guess, they only take a CMM4 aligned pulse? >>>> >>>> On 11/9/2015 4:21 PM, Forrest Christian (List Account) wrote: >>>> >>>> We have recently become aware of a potential issue when using a >>>> SyncInjector with a PMP450i. The short version of this issue is that with >>>> certain cable runs (mostly longer ones), a PMP450i will refuse to accept >>>> the sync from the SyncInjector as valid, even though the pulse is perfectly >>>> valid and should be accepted by the PMP450i. >>>> >>>> Currently, there are two ways this can be fixed. Since the pulse is >>>> valid, but just not recognized as valid by the currently shipping PMP450i >>>> firmware, Cambium could fix this in software. I believe they are >>>> currently investigating this as an issue, and I honestly expect them to >>>> release a fix assuming it isn't a major issue to do so. If this happens, >>>> it should address all of the existing SyncInjectors in the field which our >>>> customers may want to use in the future with a a PMP450i. >>>> >>>> The second way to fix this issue is for us to modify our sync pulse >>>> slightly so that it is in line with what the PMP450i is expecting. >>>> Because this modification has some additional benefits beyond better >>>> interoperability with the current PMP450i firmware (such as the modified >>>> pulse being less likely to induct noise into adjoining cables), we have >>>> decided to proceed down this path as well. >>>> >>>> During the next week or so, we will begin shipping Revision I0 of our >>>> Gigabit SyncInjector Product. The first of these are currently working >>>> their way through our assembly line. This version contains improved >>>> support for voltages above 58V and also the waveform modification mentioned >>>> above. It should be functionally identical to the earlier Revision H0 >>>> SyncInjectors. It is not our intention to update our non-gigabit >>>> injectors at this time. >>>> >>>> If you are currently having problems with sync over power on a Gigabit >>>> SyncInjector and a PMP450i, please send an email into >>>> <[email protected]>[email protected] and we will work with >>>> you to ensure you have hardware which will work with your hardware. >>>> >>>> > > > -- > *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* > Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 > <[email protected]>[email protected] | <http://www.packetflux.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 [email protected] | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
