Desde mediados de 2025, un fenómeno técnico está afectando a un número significativo de dispositivos GPS en flotas, rastreadores IoT y equipamiento legado: la transmisión de fechas incorrectas, errores en la posición o incluso la ausencia total de datos, no por fallas en los satélites GPS, sino por limitaciones internas de los chipsets que usan algunos equipos GPS antiguos o de bajo costo.
🛰️ ¿Qué es el GPS Week Number Rollover?
El sistema GPS transmite tiempo y fecha utilizando un conteo de semanas desde 5 de enero de 1980. Ese número de semana se transmite en 10 bits, lo que significa que solo puede contar hasta 1,023 semanas (~19.6 años) antes de “reiniciarse” a cero, un proceso llamado GPS Week Number Rollover (WNRO).
Este fenómeno ha ocurrido ya varias veces: en 1999, en 2019, y ciertos dispositivos están experimentando un efecto similar ahora debido a cómo fueron diseñados sus chipsets o firmware.
📍 Principales chipsets / casos afectados
🔹 MediaTek MTK2503 / MTK2503D (2025)
Este es uno de los casos más difundidos en 2025:
Qué es: Un chipset económico con GNSS integrado que también incluye modem 2G y Bluetooth, muy usado en GPS trackers baratos y genéricos.
Qué ocurrió: El contador de semanas del MTK2503 estaba programado con una fecha base que se alcanzó exactamente tras 1,024 semanas desde enero de 2006, lo que desencadenó un rollover el 17–18 de agosto de 2025.
Qué fallas produce: El dispositivo reporta la fecha 2006 en lugar de 2025.
Muchos equipos dejan de actualizar posición, o si “trabajan” solo muestran coordenadas antiguas porque la fecha no tiene sentido para la plataforma de rastreo.
Funciones dependientes del tiempo (historial, alarmas, geocercas con tiempo, sincronización) se desconfiguran o dejan de funcionar.
👉 Este problema se evidencia en marcas populares en el mercado (Concox/WeTrack, Bitrek, SinoTrack, Coban, Xeeletech, Micodus, etc.), todas con dispositivos basados en MTK2503/MT3333 que están mostrando datos de tiempo incorrectos o fallando por completo.
🔹 Otras series y modelos afectados por rollover o diseño antiguo
🚩 MOBATIME GPS 4500 / GNSS 3000 V1 y versiones antiguas
Equipos industriales/cronómetros de sincronización que también utilizan GPS para tiempo preciso pueden mostrar fecha errónea o perder sincronización si no se actualizan antes de sus fechas internas de rollover en 2025.
🚩 Receptores JRC diseñados con contador base antiguo
Varios modelos de GPS/compases/navboxes JRC (Japan Radio Company) también tenían un contador que volvía atrás hasta ~2005–2006 con consecuencias similares de fecha/tiempo erróneo.
🚩 Receptores marinos y algunos modelos legacy de marcas como FURUNO
Ciertas series de receptores y plotters antiguos no tienen correcciones para el rollover, y aunque algunos tienen firmware actualizado, muchos equipos fuera de soporte quedan afectados.
🚩 Casos documentados en dispositivos populares
Incluso foros de plataformas como Traccar han reportado problemas en protocolos comunes (T800x, GT02) donde los encabezados igualmente transmiten fechas de 2006 debido a rollover en firmware GNSS.
🔎 Qué está pasando en realidad con coordenadas y fechas
El GPS en sí mismo transmite la fecha y hora correctas desde los satélites, pero el firmware y hardware del chipset interpretan mal ese número de semana cuando llega al límite del contador antiguo:
📍 Esto puede provocar que el receptor GNSS:
Reporte la hora y fecha como si fuera hace ~19 años.
No entregue posición alguna porque la plataforma de rastreo descarta datos con fecha no válida.
Reporte ubicaciones inconsistentes o erróneas si el equipo se basa en cálculos temporales internos para referenciar coordenadas.
⚠️ Principales motivos por los que estos dispositivos fallan
🛠️ 1. Diseño legado del contador de semanas
Chipsets y firmware antiguos no contemplaron que el contador de semanas se “rebobinaría” tras un ciclo de ~19.6 años, por lo que muchos códigos internos interpretan mal la fecha cuando ocurre el rollover.
🔒 2. Falta de soporte o actualizaciones
Muchos dispositivos sencillos o económicos no recibieron actualizaciones de firmware que ajustaran este límite, quedando sin corrección posible.
💡 3. Arquitectura simple del chipset
Algunos integran el manejo del contador de semanas directamente en hardware (chipset) sin posibilidad de ajuste desde software, lo que limita cualquier reparación vía firmware.
🛠️ Cómo mitigar estos problemas
✔️ 1. Actualizar firmware si el fabricante lo permite
Algunos productos profesionales (GNSS industriales, chronos, sincronizadores) han lanzado firmware o parches para manejar el rollover correctamente.
✔️ 2. Aplicar corrección a nivel de plataforma
En servicios de rastreo es posible corregir el timestamp en el servidor: identificar fechas claramente erróneas (por ejemplo 2006) y reemplazarlas con tiempo de servidor o estimado, sin cambiar hardware.
✔️ 3. Reemplazar hardware obsoleto
Si el dispositivo no puede actualizarse o corregirse, la solución definitiva es reemplazarlo por un chipset moderno que:
Soporte señales GNSS modernas (GPS CNAV con contador extendido).
Permita actualizaciones futuras.
No tenga limitaciones de semana.
🧠 Conclusión
El problema no radica en que el sistema GPS global “esté fallando”, sino en que equipos basados en determinados chipsets obsoletos o con firmware sin manejo moderno del contador de semanas ahora muestran:
📌 Fecha incorrecta (generalmente revertida ~19 años).
📌 Datos de posición no válidos o inconsistency.
📌 Equipos que dejan de transmitir datos útiles en plataformas GPS.
Estas fallas son especialmente visibles en equipos económicos, sin soporte activo, con chipsets antiguos, y en aplicaciones donde la fecha y hora precisa es crítica para funcionamiento correcto de servicios y análisis histórico.
