Paso 3: limitaciones
Hay muchos agentes en juego en este proyecto:
(1) la MTKLIO(s), requieren un GPS "fix" para publicar su ubicación, el número de satélites visto y corregido en cualquier momento se verá afectado por varios factores tales como la unidad sea en interiores o exteriores, con cielos despejados, etc.. Los satélites más podemos conseguir una solución en la más exacta la información de ubicación.
(2) comunicación de datos se realiza través de GPRS (es decir una red celular, tiene por qué necesitamos la SIM) y está sujeto a la unidad que se obtiene una señal "en el campo".
(3) la unidad está alimentada por una batería recargable cuando se implementa, potencia los niveles va a sufrir con el uso continuado de GPS.
(4) mensajes viajan a través de canales de terceros (flujo de datos, es decir, PubNub), aunque nunca he encontrado esto para ser cualquier cosa que no sea resistente, robusta y aligeramiento rápido! [*]
(5) si tiene acceso el navegador supervisor sobre un módem por cable los datos de localización obtenidos no es muy precisos y en el caso de una valla de pequeño radio, puede dar falsos positivos al calcular si una unidad está fuera de rango.
Las imágenes en este paso muestran salida serial (útil para saber lo que está haciendo el dispositivo en cualquier dado tiempo depurar) y la caída hacia fuera y la reconexión automática de un canal durante la prueba. Puede ver claramente la unidad de recepción de una notificación de "incumplimiento", seguida de un "OK" como el número de satélites visto variado.
[*] durante las pruebas he encontrado que no hook-up con un canal [publish() o subscribe()] 7 siete veces consecutivas hará que la unidad de "colgar". Supongo que aquí, pero es probable que sea una defensa de la seguridad en extremo de PubNub para proteger la integridad de la network(?) de corriente
