Stap 3: beperkingen
Er zijn vele agenten in het spel in dit project:
(1) de MTKLIO(s), vereisen een GPS "fix" te publiceren hun locatie, het aantal satellieten gezien en vast op een bepaald moment zal worden beïnvloed door verschillende factoren, zoals of de eenheid is binnenshuis of buitenshuis, met een heldere hemel enz. De meer satellieten kunnen we een oplossing op, des te nauwkeuriger de rapportage van de locatie.
(2) de datacommunicatie via GPRS wordt uitgevoerd (dat wil zeggen een cellulair netwerk, het heeft daarom we de SIM-kaart moeten) en is onderworpen aan de eenheid een signaal "in het veld" ophalen.
(3) de eenheid wordt gevoed door een oplaadbare batterij wanneer ingezet, macht niveaus zal lijden met het voortdurende gebruik van de GPS.
(4) berichten reizen via derde-partij kanalen (dwz PubNub-gegevensstroom), hoewel ik heb nooit vond dit als iets anders dan veerkrachtig, robuust en lightening snel! [*]
(5) indien de toezichthoudende webbrowser toegang heeft tot de locatiegegevens die verkregen is via een kabelmodem niet erg nauwkeurig en in het geval van een kleine hek straal, valse positieven kan geven bij de berekening als een eenheid is out-of-range.
De afbeeldingen op deze stap tonen uitgang voor seriële (handig om te weten wat het apparaat doet op een gegeven tijd wanneer foutopsporing) dropping uit en de auto opnieuw verbinding van een kanaal tijdens de test. U ziet duidelijk de eenheid ontvangst van een kennisgeving van "inbreuk", gevolgd door een "OK" als het aantal satellieten gezien gevarieerd.
[*] tijdens het testen heb ik gevonden dat niet hook-up met een kanaal [publish() of subscribe()] zeven (7) achtereenvolgende keer zal de eenheid 'loopt vast'. I 'm guessing hier, maar het is waarschijnlijk een defensie van veiligheid aan PubNub het einde ter bescherming van de integriteit van het stream-network(?)
