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]> 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]> 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]>[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>
