I am re-publishing a Field Service Bulletin from 2020 to highlight the potential for GPS synchronization loss when using Cambium uGPS, cnPulse or ePMP 1000/2000/3000 APs using integrated GPS. While many of you may have upgraded your sync hardware since 2020, if you are using any of these devices that are running firmware version AXN5.1.1 or lower, you may lose synchronization on leap year 2024 (January 1, 2024). Please reference the Field Service Bulletin below for details.
Is AXN_5.1.1.8513 subject to this issue? or is it considered newer than AXN5.1.1?
2 Likes
AXN_5.1.1.8513 is a newer version of the firmware and should not be prone to the GLONASS GPS sync loss issue outlined in FSB 9079.
We are using cnmatrix switches with cnPulse, set to CMM on our 3000 units. How do we check if we are in the clear?
Our ePMP 1000/2000 APs are running GPS firmware version AXN_5.1._8174
I tried to update up to 4.7.0.1 with no change in GPS firmware; even tried pushing it twice through Maestro and then manually once more on the AP. Is this AXN_5.1._8174 version also a newer version than 5.1.1?
Unfortunately there isn’t a way to view the AXN FW level of the cnPulse from the cnMatrix. If the cnPulse was purchased after January 2020 there is a high probability that they have the updated firmware. Sorry that I don’t have a good answer on this one.
Yes, AXN_5.1.8174 is newer and not susceptible to this issue.
I’m running six ePMP1000 sectors (6 GHz Connectorized Radio with Sync) on three 40MHz-wide licensed channels in ABCABC configuration, current software version 4.8, GPS firmware version AXN_5.1._8174. Seems o work, but just curious - is there a way to not rely on satellites for sync? I’m a bit concerned that the Russians might cause some interference to make GPS/GLONASS not work properly over Poland (I’ve heard of such incidents over the Baltic Sea and I’m fairly close). NTP over a gigabit LAN from a common NTP server on the same LAN might perhaps be accurate enough, since it’s relative timing between sectors that matters (not absolute UTC time). Or perhaps there are plans to implement IEEE1588 PTP as an alternative to GPS sync?
Aside from a long holdoff timer, I don’t believe there are a ton of options currently. In a pinch could you get away with dropping them down to 20Mhz channels (yes, probably overlapping a few of the sectors by 5Mhz) and not having to rely on Sync? Or are you required to leave them on 40Mhz due to licensing restrictions?
Far from a perfect option, but may help get by until GPS was restored.
Hi. The best solution of course would be for the international community to hold Russia to it’s International Agreements on the Global Positioning System & the Global Navigation Satellite System they’ve made.
In lieu of that – and depending what AP’s you’re using – the full 2000 / 3000 / 4500 AP’s (full, not LITE) are capable of Sync over Ethernet via an external source (eg CMM) and that ‘might’ allow you to physically shield the GPS/GLONASS antenna from nearby jamming with an RF shield, and to increase the SNR on the satellite Sync Source.
Even on an AP with an attached GPS/GLONASS antenna, I’ve heard some people use small metal encloses (shaped like an empty tuna can) to shield the antenna from adjacent interference while allowing it to still ‘see’ the southern sky – although I’m not sure how beneficial that may be or not. But that might be worth a try? 
no way to not rely on GPS with this hardware. The solution would be time sync over ethernet (SyncE) but that is not as easy as syncing to NTP since the radio sync is continuously checked and corrected as soon as there is enough drift and NTP is too slow for this.
You can use a long hold-off timer but the drift in the radio is such that this can cause issues.
Using an epmp3000 in back to back split sector mode would mitigate the front/back drift as it would be exactly the same but again not perfect.
having a secondary GPS sync system such as Packetflux which is capable of seeing two different constellations can mitigate GLONASS interference issues but in reality if the Russians wanted to take out communiactions in the area they would just need to spray RF energy in all bands ( not that hard to do) and get the noise floor up to near the recievers discriminators limits which would knock everything offline anyway.