Schnelle Implementierung eines auf 10 cm genauen Echtzeit-Ortungssystems

Funkortungssysteme haben sich zu einer allgegenwärtigen Funktion in nahezu jeder Art von mobilem Gerät und den damit einhergehenden Anwendungen entwickelt. Unter den Funkortungssystemen spielen Echtzeit-Ortungssysteme (RTLS), die auf Ultrabreitband-HF-Kommunikation basieren, eine zentrale Rolle dabei, Informationen zum Standort auch dann zur Verfügung zu stellen, wenn bekanntere Technologien wie GPS dazu nicht mehr in der Lage sind.

Bei wachsender Nachfrage nach immer genaueren RTLS stehen die Entwickler der Komplexität von Präzisionsmethoden wie Zwei-Wege-Kommunikation oder TDOA (Time Difference of Arrival) gegenüber.

Ein integriertes Modul und eine Software von Decawave stellen Entwicklern eine einfachere RTLS-Lösung zur Verfügung. Diese ermöglicht es, genauere Ortungsergebnisse mit minimalem Aufwand zu erzielen.

Dieser Artikel prüft RTLS-Anwendungen und -Algorithmen, einschließlich der Zwei-Wege-Kommunikation und TDOA, und geht auf Kompromisse bei der Implementierung ein, die mit den unterschiedlichen RTLS-Methoden einhergehen. Daraufhin stellt der Artikel einen Ultrabreitband-Transceiver von Decawave vor, wobei besonders auf die speziellen Anforderungen an die Entwicklung eingegangen wird. Abschließend befasst sich der Artikel mit der Softwarearchitektur von Decawave und der zugehörigen Firmware-Entwicklung. Dabei wird auf spezielle Methoden zur Entwicklung von Benutzeranwendungen auf der Plattform von Decawave eingegangen.

Die Rolle der RTLS

Präzise RTLS haben sich als eine effektive Methode zur Standortbestimmung oder zur Überwachung von Menschen oder mobilen Gütern in Bürokomplexen, Lagern, Produktionsanlagen und auf Fließbändern erwiesen. Bei dieser Methode tauscht ein mobiles Objekt (Tag) Informationen mit unbeweglichen Geräten (Ankern) aus, wobei Standardformate und Ultrabreitbandtechnologien basierend auf LR-WPAN (Low-Rate Wireless Personal Area Networks) gemäß IEEE 802.15.4-2011 verwendet werden. Dadurch, dass die Distanz zwischen Tag und verschiedenen Ankern bestimmt wird, können Anwendungen die relative Position des Tags im Verhältnis zu den bekannten Ankern bestimmen – und dadurch die absolute Position des Tags.

RTLS-Methoden

RTLS-Anwendungen nutzen eine Vielzahl an Methoden zur Bestimmung einer Distanz. Die einfachste Herangehensweise dabei ist, dass die Anwendung oder der Tag die Parameter der Empfangsfeldstärke (RSSI), die den meisten Transceivern zur Verfügung stehen, verwenden können, um die relative Position zu den sendenden Ankern bestimmen zu können. Aufgrund vieler Faktoren, die das Link-Budget beeinflussen können, kann diese Methode jedoch keine exakte Standortbestimmung liefern. Viele aufkommende, auf RTLS-basierende Anwendungen verlangen hingegen eine absolute Bestimmung der Position, die auf ein paar Zentimeter genau ist.

Hochpräzise RTLS nutzen Laufzeitmethoden, die gegenüber starken Veränderungen der HF-Signalstärke nahezu immun sind. Bei dieser Methode kann die Position des Tags durch die Messung der Zeit bestimmt werden, die ein HF-Signal benötigt, um vom Tag zu den verschiedenen Ankern zu gelangen. Mit Hilfe der bekannten durch die Luft bedingten Laufzeitverzögerung des HF-Signals können RTLS-Anwendungen die Laufzeit in Distanz übersetzen.

Das ist zum Beispiel der Fall, wenn die Laufzeit zwischen einem Tag und einem der drei Anker exakt gleich ist. Dieser Fall kann nur dann eintreten, wenn der Tag zu jedem Anker dieselbe Distanz hat. Da die Anwendung die exakte Position jedes Ankers kennt, kann sie die absolute Position des Tags bestimmen.

Um die Laufzeit vom Tagsender jedoch messen zu können, muss der Ankerempfänger dieselbe Zeitbasis wie der Tag aufweisen, um die Informationen zur Zeit, die in der Nachricht des Tags enthalten sind, korrekt auswerten zu können. Wenn die Zeitbasis des Ankers vor oder nach der des Tags liegt, ist die berechnete Distanz kürzer beziehungsweise länger als die tatsächliche Distanz.

Eine RTLS-Methode geht dieses Problem gezielt an, indem sie für Tagsender und Ankerempfänger eine Zeitsynchronisierung durchführt. Dadurch wird sichergestellt, dass jeder Anker die Nachricht basierend auf der Zeitbasis des Tags empfängt. Die Implementierung einer Zeitsynchronisierung kann bestenfalls schwierig und in RTLS-Anwendungen mit sich hin- und herbewegenden drahtlosen Tags einfach nicht realisierbar sein.

Eine weitere Methode, TDOA, synchronisiert nur die Anker und beseitigt so die Herausforderung, die mit sich hin- und herbewegenden Tags einhergeht. Um die Position zu bestimmen, nutzt die RTLS-Anwendung die Unterschiede zwischen den Ankunftszeiten eines Tagsignals, die von mehreren Ankern erfasst wurden. Hierzu nimmt man beispielsweise das obige Beispiel der drei Anker (A₁, A₂, und A₃), die alle dieselbe Distanz zum Tag aufweisen. Wenn TDOA für den jeweiligen Anker, nachdem sich der Tag bewegt hat, 0, 1 Nanosekunde (ns) und 0 beträgt, bedeutet das, dass sich der Tag circa 30 Zentimeter (cm) in direkter Linie weg vom Anker A₂ bewegt hat (bei einer HF-Ausbreitung mit Lichtgeschwindigkeit). Die TDOA-Anforderungen an die Ankersynchronisierung sind deutlich einfacher zu realisieren als der Versuch, Anker und Tags zu synchronisieren. Nichtsdestotrotz hängt die Genauigkeit dieser Methode von sehr präziser Synchronisierung ab. Selbst ein Unterschied von einer Nanosekunde bei der Synchronisierung kann einen Unterschied von mehreren Zentimetern bei der Ortsbestimmung ausmachen.

Zwei-Wege-Kommunikation

RTLS-Methoden mit Zwei-Wege-Kommunikation beseitigen die Notwendigkeit einer präzisen Zeitsynchronisierung komplett, erfordern aber dennoch eine Übertragungskapazität im Tag. Durch diese Herangehensweise kann die Unsicherheit unterschiedlicher Zeitbasen vermieden werden. Und zwar indem ermöglicht wird, dass Tag und Anker untereinander Informationen zur Zeit austauschen können. Statt ihre Zeitbasen zu synchronisieren, nutzen der Tag und die Anker ein kurzes bidirektionales Nachrichtenprotokoll, das eine präzise Laufzeitbestimmung und Berechnung der Tagposition zulässt.

So sendet ein Tag ein kurzes Identifikationssignal an die Anker in seiner Umgebung. Jeder Anker, der das Signal des ersten Identifikationssignals des Tags empfängt, nimmt mit Hilfe eines bidirektionalen Datenaustausches Verbindung mit dem Tag auf. Dieser dient dazu, die Laufzeit trotz unterschiedlicher Zeitbasen zwischen Ankern und Tags zu bestimmen.

Bei diesem Zwei-Wege-RTLS-Protokoll, definiert Decawave diesen Prozess als eine Erkennungs- und Kommunikationsphase. Während der Erkennungsphase sendet ein Tag periodisch ein kurzes Identifikationssignal und wartet dann auf eine Antwort von einem der Anker. Nachdem sich Tag und Anker identifiziert haben, erhalten die gekoppelten Tags und Anker über einen kurzen Zwei-Wege-Nachrichtenaustausch die benötigten Informationen, um die Entfernung zu berechnen.

Abbildung 1: Im Zwei-Wege-Kommunikationsprotokoll von Decawave nutzen Tags und Anker eine Reihe von Nachrichten, um die Erkennung abzuschließen und Informationen zur Kommunikation bereitzustellen. (Bildquelle: Decawave)

Für Entwickler kann die Implementierung dieser präzise geplanten Nachrichtenaustauschprotokolle und der zugehörigen Ultrabreitband-Funkteilsysteme eine anspruchsvolle Aufgabe sein. Doch dank des DWM1001-Moduls von Decawave, können Entwickler mit kleinstem Aufwand ihre Anwendungen mit präzisen RTLS-Lösungen ausstatten.

Integriertes RTLS-Modul

Das DWM1001-Modul von Decawave stellt eine komplette RTLS-Implementierung zu Verfügung. Dabei wird der Decawave DW1000-Ultrabreitband-Transceiver mit der Wireless-MCU NRF52832 von Nordic Semiconductor und dem 3-Achsen-Bewegungssensor LIS2DH12 von STMicroelectionics ausgestattet. Während der DW1000 ein HF-Signal gemäß der IEEE 802.15.4-2011 bereitstellt, stellt die NRF52832-MCU ihre eingebettete Firmware für RTLS-Anwendungen zur Verfügung. Die LIS2DH12-Sensoren spielen eine zentrale Rolle in der Energieverwaltung.

In jeder ausgeklügelten HF-Anwendung stellt das RF-Design normalerweise eine der größten Herausforderungen dar. Das gilt besonders bei mobilen Anwendungen, die minimalen Platzbedarf und Energieverbrauch erfordern. Das DWM1001-Modul nimmt sich dieser Themen an, indem es das integrierte HF-Design des DW1000 in vollem Umfang nutzt (Abbildung 2).

Abbildung 2: Der Decawave DW1000-Sender fasst Funkwege und digitale Steuerung in einem einzigen System gemäß IEEE802.15.4-2011 zusammen. (Bildquelle: Decawave)

Der DW1000 stellt einen kompletten Ultrabreitband-Transceiver bereit, der ein HF-Frontend enthält, das sechs Kanäle gemäß IEEE802.15.4-2011 von 3,5 GHz bis 6,5 GHz bei Standard-Bit-Raten von 110 Kbit/s, 850 Kbit/s und 6,81 Mbits/s unterstützen kann. Außerdem steuert das integrierte digitale Steuerungsteilsystem des Geräts den Transceiver und unterstützt sowohl die Zwei-Wege-Kommunikation als auch TDOA-RTLS-Systeme mit einer Ortungsgenauigkeit von 10 cm. Ein integrierter, einmal programmierbarer Speicher (OTP) erlaubt es Entwicklern, Daten für die Kalibrierung und Fehlerbeseitigung zu speichern, während der konfigurierbare dauerbetriebene Speicher (AON) des Gerätes die Konfigurationsdaten während der unten beschriebenen Modi aufrechterhält.

Im Betrieb sendet und empfängt das Gerät Standard-Frames gemäß IEEE802.15.4-2011, die einen Synchronisierungs-Header (SHR), einen physischen Layer-Header (PHR) und bis zu 127 Byte an Daten umfassen, die die gesamte PSDU (PHY Service Data Unit) ausmachen. Neben den Standard-Frames unterstützt das Gerät auch ein proprietäres Frame-Format, das bis zu 1023 Byte an Daten für Anwendungen bereitstellt, die größere Daten-Payloads senden müssen und IEEE802.15.4-2011 nicht entsprechen müssen.

Bei konformen Anwendungen können Entwickler aus einer Reihe von Betriebsmodi mit voreingestellten Kombinationen aus Datenraten, Datenmenge und Länge der Präambel wählen, um speziellen Anwendungsfällen für die Zwei-Wege-Kommunikation und den TDOA-Betrieb gerecht zu werden. Beispielsweise vereinen Modi, die für Fernbereichsanwendungen bestimmt sind, geringe Datenraten mit langen Präambeln, die die Erkennung und Kommunikation bei Störungen oder schwachen Signalen erleichtern sollen. Umgekehrt, unterstützen Modi mit hohen Datenraten und kurzen Präambeln Nahbereichsanwendungen. Andere Modi unterstützen diese Eigenschaften für Nah- bzw. Fernbereichsanwendungen mit Hilfe von unterschiedlichen Daten-Payloads.

Minimierung des Energieverbrauchs

In der Praxis entscheiden sich Entwickler für Betriebsmodi mit der kürzestmöglichen Frame-Größe, um den Energieverbrauch insgesamt zu verringern und das Gerät schnellstmöglich wieder in einen energiesparenden Modus zu bringen. Der DW1000 bietet eine Reihe energiesparender Modi. Während inaktiver Phasen kann das Gerät in den Ruhemodus geschaltet werden, in dem das Gerät nur 19 Milliampere (mA) verbraucht. Wenn das Gerät länger inaktiv bleibt, können Entwickler das Gerät in den energiesparenden Schlafmodus versetzen, in dem nur rund 1 Mikroampere (μA) verbraucht werden, und in den Tiefschlafmodus, in dem das Gerät maximal 100 Nanoampere (nA) (meist 50 nA) verbraucht.

Doch wie bei jedem HF-Design steigt der Energieverbrauch im aktiven Transceiver-Betrieb stark an. Um beispielsweise einen Frame gemäß IEEE802.15.4-2011 zu senden, verbrauchen längere Frame-Komponenten wie der Synchronisierungs-Header und das Datenpaket am meisten Energie.

Abbildung 3: Senden eines RTLS-Frames mit dem Decawave DW1000 führt zu einem starken Anstieg des Energieverbrauches für jede Komponente des Frames und dazu, dass Entwickler nach Betriebsmodi mit dem sinnvoll kürzesten Synchronisierungs-Header und der geringsten Daten-Payload suchen. (Bildquelle: Decawave)

Eine weitere Herausforderung für energiesparende Designs stellt der noch höhere Energieverbrauch dar, der mit dem Empfang von Signalen einhergeht (Abbildung 4). Entwickler können den DW1000 so programmieren, dass dieser in einen energiesparenden Modus zurückkehrt, sobald die Übertragung oder der Empfang abgeschlossen ist. Und trotzdem, die Natur von Standardprotokoll und -Frames lässt nur wenige Möglichkeiten offen, den Energieverbrauch zu reduzieren.

Abbildung 4: Das Empfangen eines Signals verbraucht noch mehr Energie als das Senden, was hauptsächlich der längeren Dauer der Detektion der Präambel zuzuschreiben ist. (Bildquelle: Decawave)

Der DW1000 verfügt über eine einzigartige energiesparende Funktion, um den Energieverbrauch während der Präambel-Empfangsphase zu reduzieren. Statt den Empfänger auf Dauerbetrieb operieren zu lassen, können Entwickler auf dem Gerät einen speziellen Präambel-Sniff-Modus programmieren. Dabei treibt der DW1000 den Empfänger periodisch an, sucht nach der Präambel und kehrt in den Ruhemodus zurück, wenn die Präambel nicht gefunden wurde (Abbildung 5).

Abbildung 5: Entwickler können den Energieverbrauch, der mit dem Empfängerbetrieb einhergeht, reduzieren, indem sie die Sniff-Funktion des DW1000 nutzen, bei der dieser zwischen Ruhemodus und aktivem Empfangsmodus wechselt. (Bildquelle: Decawave)

Funktionen wie die Präambel-Sniff-Funktion sind besonders wichtig für batteriebetriebene Tags. Entwickler haben eine Vielzahl an Möglichkeiten, den Energieverbrauch während des RTLS-Betriebs zu reduzieren. Bei einer Herangehensweise werden verschiedene bekannte Verzögerungen genutzt, die, wie in Abbildung 1 gezeigt, im Zwei-Wege-Kommunikationsprotokoll vorkommen.

Beispielsweise erfolgt die Ranging-Init-Antwort des Ankers auf ein Tagsignal während der Erkennungsphase mit einer bestimmten Verzögerung. Entwickler können diese Verzögerung basierend auf der Bildrate und anderen Parametern schätzen, deren tatsächlichen Wert im Ankerdesign messen oder sogar eine spezielle Antwort-Verzögerungszeit in das Ankerdesign mit einbinden. Der Entwickler kann daraufhin den Tag des Empfängers für die erwartete Verzögerungszeit beruhigt ausschalten, ihn erneut anschalten, um nach einer Antwort zu suchen, und ihn wieder abschalten, wenn die Ranging-Init-Antwort nicht innerhalb eines angemessenen Zeitfensters eingetroffen ist.

Entwickler können die Zeit, in der das Funksignal während des Kommunikationsprozesses eingeschaltet sein muss, eingrenzen. Zum Beispiel können Entwickler das Gerät mit all den benötigten Daten und direkten Speicherzugriff nutzen, um die Übertragung zwischen DW1000 und Gastspeicher zu beschleunigen.

Während diese Maßnahmen bereits ein großes Stromeinsparpotenzial bergen, können Entwickler sogar noch bessere Ergebnisse erzielen, indem sie die Positionsaktualisierungsrate dynamisch verändern. Wenn sich ein Tag nicht mehr bewegt, besteht keinerlei Vorteil mehr darin, mit dieser energieverbrauchenden Erkennungs- und Kommunikationsphase fortzufahren. Der Tag könnte sich problemlos in den energiesparenden Schlafmodus versetzen und Updates bei nominaler Rate erst dann wieder vornehmen, wenn er anfängt, sich zu bewegen.

Das DWM1001-Modul unterstützt dynamische Ratenanpassung mit Hilfe des integrierten Bewegungssensors LIS2DH12 und der Unterstützung zweier bewegungsabhängiger Betriebsmodi: energiesparend und reaktiv. Entwickler können das Modul zur Bedienung des DW1000-Transceivers so konfigurieren, dass es sich in den Niedrigleistungsmodus begibt, sobald der LIS2DH12 bemerkt, dass sich das Modul nicht bewegt. Wenn der LIS2DH12 dann eine Bewegung feststellt, kann der Transceiver sich in den reaktiven Modus begeben, in dem der DW1000-Transceiver Updates wieder zur nominalen Rate vornimmt.

Weiterhin können Entwickler ihre RTLS-Anwendung so optimieren, dass die Update-Rate basierend auf der Geschwindigkeit und Beschleunigung des Objekts gesteuert wird. Ein sich langsam bewegendes Tag zum Beispiel benötigt möglicherweise nicht so häufig Updates, um die erforderliche Standortgenauigkeit zu gewährleisten. Wenn das Tag sich schneller bewegt, könnte die Anwendung darauf mit einer erhöhten Positions-Update-Rate reagieren.

RTLS-Entwicklung

Über die Fähigkeit hinaus, RTLS-Funktionen wie beispielsweise dynamische Updateraten zu unterstützen, bietet das Modul einen grundlegenden Vorteil in der RTLS-Entwicklung. Der DW1000-Tansceiver stellt zum Beispiel eine Reihe spezieller Schnittstellenanforderungen hinsichtlich Entkopplung, Netzwerkanpassung der Antenne, Referenzoszillator und weiterer Dinge (Abbildung 6). So stellen auch die drahtlose NRF52832-MCU und der LIS2DH12-Bewegungssensor eigene Anforderungen an das Schnittstellendesign.

Abbildung 6: Der DW1000-Transceiver von Decawave stellt strenge Schnittstellenanforderungen, um eine sichere Energieversorgung, HF und Zeitsignale zu gewährleisten. (Bildquelle: Decawave)

Obwohl fortschrittliche Geräte wie diese das Design stark vereinfacht haben, könnte die Optimierung ihrer Integration in Designs, die maximale Leistung bei minimalem Energieverbrauch erfordern, die Entwickler vor eine große Herausforderung stellen. Das DWM1001-Modul reduziert die Anforderung bei der Integration auf ein paar wenige Anschlüsse für Energie-, Erdungs- sowie digitale Schnittstellen (Abbildung 7).

Abbildung 7: Das DWM1001-Modul von Decawave vereinfacht die RTLS-Entwicklung durch ein vollintegriertes Design aus DW1000-Transceiver mit einer drahtlosen MCU und einem Bewegungssensor. (Bildquelle: Decawave)

Softwaremodell

Genauso vereinfacht das Modul die Softwareentwicklung dank seiner voreingestellten Firmware für die sogenannte PANS-Bibliothek (Positioning and Networking Stack) von Decawave erheblich. Die PANS-Bibliothek, die auf dem energiesparenden On-Chip-Bluetooth Stack der MCU (BLE) aufbaut, enthält das Open-Source Echtzeit-Betriebssystem eCos (RTOS), eine Netzwerkschichtund Anwendungsschichten, die BLE-Dienste, RTLS-Verwaltungsdienste und die Zwei-Wege-Kommunikation (TWR) unterstützen.

Abbildung 8: Die PANS-Bibliothek von Decawave stellt eine umfangreiche Plattform für RTLS-Anwendungen mit Kombinationen aus Bluetooth-Stack, RTOS, Netzwerk-Layer und Anwendungs-Layer zu Verfügung. (Bildquelle: Decawave)

Bei der Entwicklung der Firmware-Anwendungen für den Betrieb der DWM1001-MCU, haben Entwickler Zugriff auf die PANS-Bibliothek durch eine umfangreiche Schnittstelle zur Anwendungsprogrammierung (API), die geeignete Eintragspunkte für jedes PANS-Modul zur Konfigurierung und Steuerung des jeweiligen Moduls enthält. Die PANS API umfasst eine Reihe an API-Sets für unterschiedliche Module, einschließlich der Programmiersprache C, Bibliotheken mit seriellen Schnittstellen (CPI und UART) sowie die BLE-Bibliothek (Abbildung 9).

Anwendungen arbeiten direkt mit diesen vier High-Level-APIs, die im Gegenzug mit Hilfe eines generischen API-Parsers, der diese Anfragen in generische API-Anfragen konvertiert, auf die PANS-Bibliothek zugreifen. Dabei stellt der generische Layer eine übliche Schnittstelle zur PANS-Bibliothek bereit.

Abbildung 9: Decawave stellt die PANS-Bibliothek durch umfassende APIs bereit, wobei jede einfachen Zugriff auf das zugehörige Threaded-Ausführungsmodel gewährt. (Bildquelle: Decawave)

Threaded-Architektur

Innerhalb dieser Architektur kommt bei der DWM1001-Firmware ein Threaded-Model zur Anwendung, das im Wesentlichen einen eigenen Thread für jedes Modul und jede Bibliothek im Stack zur Verfügung stellt. Threads für jedes dieser vier Module am Stack leiten Parsing-Anfragen an den generischen API-Parser-Thread weiter, der jede Anfrage der PANS-Bibliothek validiert, um eine geeignete Antwort zu generieren. Der generische API-Thread nutzt im Gegenzug eine Rückruffunktion, die in der ursprünglichen Anfrage enthalten ist, um die Ergebnisse des anfragenden Moduls am Stack zu erhalten.

Trotz der augenscheinlichen Komplexität dieses Multi-Layer-Systems, ist dieses Programmierungsmodell nach der Auffassung der Entwickler relativ einfach. Der Einsatz von API-Anfragen mit Rückruffunktion an unabhängige Threads hilft bei der Optimierung von Ressourcengebrauch und allgemeiner Anwendungsleistung.

Gleichzeitig ist die damit einhergehende Komplexität gekennzeichnet durch eine Reihe von APIs, die anwendungsorientierte Anfragen auf höherer Ebene in speziell optimierte Thread-Vorgänge übersetzt, die mit der DWM1001-Hardware interagieren. Das DWM1001-Programmierungsmodell vereinfacht darüber hinaus die Interaktion des Entwicklers mit dem System. Anstatt mit mehreren Threads und APIs zu interagieren, können Entwickler nun einen im System fest zugeordneten Benutzer-Anwendung-Thread nutzen.

Wie in Listing 1 veranschaulicht, rufen Entwickler den Benutzer-Anwendung-Thread mit einer simplen API-Anfrage (dwm_thread_create) auf, die die Funktion des Benutzer-Anwendung-Threads registriert (app_thread_entry).

Kopieren

  /* Create thread */

  rv = dwm_thread_create(THREAD_APP_PRIO, app_thread_entry, (void*)NULL, "app", THREAD_APP_STACK_SIZE, &hndl);

  APP_ERR_CHECK(rv);

  /* Start the thread */

  dwm_thread_resume(hndl);

Listing 1: Anhand des Thread-Modells von Decawave, registrieren und starten Entwickler den Anwendungs-Thread mit einer einfachen Anfragen an das API. (Codequelle: Decawave)

Decawave stellt einen Beispielcode für einen Benutzer-Anwendung-Thread und Rückruf zur Verfügung. Dieser Beispielcode kommt zusammen in einer virtuellen Maschine für Oracle Virtual Box einschließlich einer kompletter Toolchain, Bibliotheken und die einfache Beispielanwendung. Das für den Einsatz mit der an einen Windows-PC angeschlossenen DWM1001-DEV-Entwicklungskarte entwickelte Softwarepaket bietet einen Rahmen zum Erstellen einer eigenen RTLS-Anwendungs-Software.

In diesem Softwarepaket inbegriffen ist ein Beispielcode, der Schlüsseldesignmuster für die Benutzer-Thread-Funktion veranschaulicht (Listing 2). In diesem Beispiel legt die Benutzer-Thread-Funktion (app_thread_entry) anwendungsspezifische Konfigurationsparameter wie die Updaterate fest und registriert ihre Rückruffunktion mittels API-Funktion dwm_evt_cb_register anhand des Namens der Rückruffunktion (on_dwm_evt). Nachdem der Rückruf registriert wurde, geht der Beispiel-Thread zu dessen Hauptkreis über ̶̶̶̶̶– in diesem Fall sind dies eine Reihe an Anfragen an eine Verzögerungsfunktion, um die Verwendung von Ressourcen zu verringern.

Kopieren

void app_thread_entry(uint32_t data)

{

  .

  .

  .

  /* Update rate set to 1 second, stationary update rate set to 5 seconds */

  APP_ERR_CHECK(dwm_upd_rate_set(10, 50));

  /* Register event callback */

  dwm_evt_cb_register(on_dwm_evt, 0);

  .

  .

  .

  while (1) {

    /* Thread loop */

    dwm_thread_delay(100);

  }

}

Listing 2: Bei diesem Snippet des Firmware-Entwicklungspakets von Decawave werden Grunddesignmuster zur Registrierung des Rückrufs und Ausführung des Hauptkreises als routinierter Benutzer-Anwendung-Thread anhand eines Beispielcodes veranschaulicht. (Codequelle: Decawave)

Die Beispiel-Rückruffunktion (on_dwm_evt) demonstriert einen grundlegenden Event-Handler, der bei einem Event zur Anwendung kommt (Listing 3). Bei diesem Beispiel-Code ist das einzig gültige Event die Verfügbarkeit einer neuen Standortposition (DWM_EVT_NEW_LOC_DATA). Innerhalb des Handlers für dieses Event veranschaulicht der Code den einfachen Satz an Anfragen, die zum Abrufen von Standortinformationen, die von den Ankern generiert werden, benötigt werden. Nach Abschluss dieser Event-Verarbeitung, ruht der Rückruf.

Kopieren

/**

 * Event callback

*

 * @param[in] p_evt  Pointer to event structure

 * @param[in] p_data Pointer to user data

 */

void on_dwm_evt(dwm_evt_t *p_evt, void *p_data)

{

  int i;

  switch (p_evt->header.id) {

  /* New location data */

  case DWM_EVT_NEW_LOC_DATA:

    /* Process the data */

    printf("\nT:%lu ", dwm_systime_us_get());

    if (p_evt->data.loc.p_pos == 0) {

      /* Location engine is disabled */

    } else {

      printf("POS:[%ld,%ld,%ld,%u] ", p_evt->data.loc.p_pos->x,

          p_evt->data.loc.p_pos->y, p_evt->data.loc.p_pos->z,

          p_evt->data.loc.p_pos->qf);

    }

    for (i = 0; i < p_evt->data.loc.anchors.dist.cnt; ++i) {

      printf("DIST%d:", i);

      printf("0x%04X", (unsigned int)(p_evt->data.loc.anchors.dist.addr[i] & 0xffff));

      if (i < p_evt->data.loc.anchors.an_pos.cnt) {

        printf("[%ld,%ld,%ld]",

            p_evt->data.loc.anchors.an_pos.pos[i].x,

            p_evt->data.loc.anchors.an_pos.pos[i].y,

            p_evt->data.loc.anchors.an_pos.pos[i].z);

}

      printf("=[%lu,%u] ", p_evt->data.loc.anchors.dist.dist[i],

          p_evt->data.loc.anchors.dist.qf[i]);

    }

    printf("\n");

    break;

  default:

    break;

  }

  /* Indicate the application has finished the tasks and can now */

  dwm_sleep();

}

Listing 3: Das Snippet der Beispiel-Anwendung von Decawave veranschaulicht einen Rückruf, der einen grundlegenden Event-Handler für den Zugriff auf neue Standortinformation bereitstellt. (Codequelle: Decawave)

In einer kompletten RTLS-Anwendung für das Internet der Dinge (IoT) etwa würden Tags und Anker über Routing-Anker kommunizieren, die mit einem internetfähigen Gateway-System verknüpft sind. Decawave bereitet derzeit einen zweiten Release seines Firmware-Pakets vor, das eine entsprechende Gateway-Unterstützung über ein auf Linux basierendes Softwarepaket bietet, in dem bekannte IoT-Nachrichtenprotokolle wie HTTP, WebSockets, MQTT und AMQP enthalten sind.

Fazit

RTLS spielt eine zunehmend wichtige Rolle in einer Vielzahl an Anwendungen. Obwohl RTLS-Methoden auf einem relativ simplen Prinzip basieren, erfordert die Implementierung dieser Methoden ein ausgeklügeltes HF-/Analog- und Systemdesign und eine durchdachte Softwareentwicklung, um maximale Genauigkeit mit minimalem Energieverbrauch zu gewährleisten.

Das DWM1001-Modul von Decawave stellt ein komplettes RTLS-System bereit, das den integrierten DW1000-Ultrabreitband-Transceiver von Decawave mit einer drahtlosen MCU und einem Bewegungssensor vereint. Anhand dieses Moduls und des zugehörigen Softwarepakets, können Entwickler schnell hochpräzise batteriebetriebene RTLS-Systeme implementieren.