Thanks, that's makes more sense. Yeah, it's really weird. All APs say
they lose sync at the same time which points to the SyncInjector, but
all of the stats look fine. As far as voltage, I have a couple sites on
regulated 24 and a couple others on Mean Well AD-155's which put out
27.6 float voltage. I've sat and watched the pwr2 input on the base unit
(my utility monitor with old linear SyncPipe supplies so I can see AC
voltage swings) when this happens and I see no changes. Plus I have a
shunt to monitor battery charge and discharge which also doesn't change.
So I don't believe we're having any funky power issues.
The used pulses counter looks fine so far, 3600/hr (well, +/-1 which is
probably just network/processing delay). No problems today though. I'll
let this run and see if there's any change next time it happens.
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9443437
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9447037
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9450637
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9454237
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9457837
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9461437
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9465037
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9468637
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9472237
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9475837
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9479437
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9483038
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9486637
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9490237
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9493838
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9497438
SNMPv2-SMI::enterprises.32050.2.1.27.5.21 = INTEGER: 9501037
On 11/10/2015 3:11 PM, Forrest Christian (List Account) wrote:
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]
<mailto:[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]
<mailto:[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:
Inline image 5
Interesting things happen when you shoot this into a long cable:
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:
Inline image 4
On Mon, Nov 9, 2015 at 4:02 PM, George Skorup
<[email protected] <mailto:[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]
<mailto:[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] <mailto:[email protected]> |
http://www.packetflux.com <http://www.packetflux.com/>
<http://www.linkedin.com/in/fwchristian>
<http://facebook.com/packetflux> <http://twitter.com/@packetflux>
