All,
While the investigation into the root cause continues with the GPS chipmaker and others, the symptoms and recovery recommendations are contained in the Field Service Bulletin below. While we believe that this was a one-time occurrence due to a satellite maintenance procedure performed on news year eve, the recovery procedures in the FSB are recommended by Cambium in the slight chance there are still anomalies being seen.
https://www.cambiumnetworks.com/support/field-service-bulletins/fsb9079/
Chuck
1 Like
Plz also note other PMP like radwin 5k GPS sync , wimax, and 4g operator synchronization is not affected. So satellite maintenance is not root cause but something related to cambium specific and need deeper analysis
Thanks Chuck for the bulletin.
Some more inputs here Cambium PMP 100 is also affected along with all the other products mentioned.
Also The GPS chipset having GPS+Glonass support enabled faced such issues unlike only GPS enabled chips in the GPS.
need to find out the reason for that.
Also The probabilities of next occurance and the permanent fixes.
Regards
Debasish Dash
Debashish,
You are seeing this issue on a PMP100 because it is most likely getting it's sync from a uGPS. The root cause in this case is the uGPS and not the PMP100. I have updated the FSB to include the recent findings regarding the chipset being adversely affected by the GLONASS leap year adjustment. Updated FSB can be viewed at the following:
https://www.cambiumnetworks.com/support/field-service-bulletins/fsb9079/
Chuck
@ashutoshpandey,
First draft of the FSB was based upon our findings at the time. See the latest version of the FSB for the actual root cause. Keep in mind tha the FSB is intended to provide the recovery procedures and not primarily intended to provide a root cause.
Updated version: https://www.cambiumnetworks.com/support/field-service-bulletins/fsb9079/
Chuck
1 Like
Thanks for your reply Chuck!. Feels good when you personally track the replies on forum.
The reason i mentioned pmp 100 was in the bulletin it was mentioned pmp 450 were affected but PMP 100 wasnt mentioned.Anyway as of now , we have the general idea that the GPS chipset made by Siera Wireless has some issue with adapting the transition of the new date.
Anyway we will wait for the RCA and hope a fix will come soon before the 2024 (the next leap year) and please also note that Feb 2020 has also the unique date which occurs once in 4 years . We shall be ready for that too.
Regards
Debasish Dash
dear team, as per new fsb " CURRENT STATUS OF INVESTIGATION: The issue was cause by the GLONASS System Days Since Leap Year rollover that happens on every Leap Year at 00:00 Moscow Time. The GPS Chipset did not handle this rollover properly in firmware AXN_5.1.1 and it affects both UGPS and cnPulse devices with a GPS chip running this firmware. By now, it may have self-recovered, but if anything is lingering, a power cycle of the GPS device is required. This can be done via the AP if it is powered by the AP otherwise it will have to be done manually." it is clear that having addional glonass module on chipset/sw created issue. please check if we can run using single GPS chipset/sw as others running like radwin PMP, wimax, LTE operator
Well thanks Chuck.
While this one occurrence may have been due to satellite maintanence. We are seeing repeated GPS sync lost errors, sometimes they recover and sometimes they are fatal.
Further investigation on our end is starting to reveal this as pointing to a software bug in 16.1 and 16.0.1 (PMP450 and PMP450m) with different AP hardware versions.
When downgrading some APs from version 16.1 to version 16.0.0.1 seems to recover cnPulse sync on fatal loss for the PMP450m (hardware version 090a76)
When downgrading some APs from version 16.0.1 to version 16.0.0.1 or version 15.2.1 seems to recover uGPS sync on fatal loss for the PMP450 (hardware version 062618 and 081518).
For PMP450 APs with hardware version 060419, cnPulse sync seems to be stable with version 16.1.
