-
Die
vorliegende Erfindung bezieht sich auf ein Datenübertragungssystem und insbesondere
auf ein Datenübertragungssystem,
bei dem während
kurzer Zeit aber oft mit minimalem Energieverbrauch Datenimpulse übertragen
werden müssen.
Die vorliegende Erfindung bezieht sich ebenfalls insbesondere auf
ein System, das angewandt werden kann in engster Nähe anderer
identischer Systeme.
-
Es
gibt mehrere Applikationen, in denen kurze Datenbursts übertragen
werden müssen,
beispielsweise zum Schaffen einer kontinuierlichen Überwachungsfunktion
eines Sensorsignals zu einem Fernempfänger. Wo es viele derartiger
Systeme geben kann, die nahe beieinander arbeiten sollen, gibt es
auch die Notwendigkeit, einen Zusammenstoß zwischen den Systemen zu
vermeiden. Dies kann dadurch erreicht werden, dass verschiedene Übertragungsfrequenzen
verwendet werden, aber dies ist in Bezug auf die Bandbreite ineffizient
und steigert die Kosten und den Energieverbrauch des Systems.
-
Das
US Patent 5.481.259 beschreibt ein Fern-Messgerät-Auslesesystem mit einer Anzahl Messgerät-Schnittstelleneinheiten,
die zu Gruppen zugeordnet sind. Jede Gruppe hat eine zugeordnete Schlafrate,
die gegenüber
der Schlafrate der nächsten
Gruppen vorgeschoben ist, damit man für alle Messgerät-Schnittstelleneinheiten
nahezu denselben Betrag an Gesamtenergieeinsparung hat. Aber
US 5.481.259 besagt nicht über Funkstörung mit
Signalzusammenstoß zwischen
Systemen.
-
US
Patent 5.752.201 beschreibt ein Funktelefon-Kommunikationssystem,
das eine Anzahl Steuerfüllnachrichten
spezifiziert, die übertragen
werden sollen und ermöglicht
es, dass ein mobiles Endgerät während der Übertragung
der Nachrichten in eine Energiesparmode geht. In einer Ausführungsform
ist die Anzahl n aufeinander folgender Steuerfüllnachrichten variabel und
das System reagiert auf eine Änderung
in dem Wert von n zum Zusammenstellen und Übertragen einer Nachricht zu
dem Endgerät
um einen Stromwert n anzugeben. Die Beschreibung besagt, dass es
erwünscht
ist, mehr als nur eine derartige Nachricht zu benutzen, damit vor
Verlust von Information durch Funkstörung geschützt wird. Ein Nachteil ist
die zusätzliche
Kommunikationskanalkapazität,
die erforderlich ist um die doppelten Nachrichten unter zu bringen.
-
Beispiele
von Systemen mit derartigen Anforderungen umfassen Herzschlagüberwachungssysteme,
wobei ein Herzschlagsignal von einem Sensor zu einer Emp fangsanordnung übertragen wird.
Ein weiteres Beispiel sind Körperüberwachungssensoren
für Übungsapparatur,
beispielsweise Lauf- oder Rennradschuhe, wo ein an dem Fuß des Benutzers
gemessenes Geschwindigkeitssignal (unter Verwendung eines Beschleunigungsmessers) zu
einer Empfangsanordnung in der Hand des Benutzers oder am Puls desselben übertragen
wird. In dem letzteren Fall kann es sein. dass viele derartige Systeme
nahe beieinander angewandt werden, beispielsweise in einer Turnhalle
oder auf einem Sportfeld, in einem Radrennkurs oder beim Marathonlauf.
-
Es
gibt deswegen einen Bedarf an einem preisgünstigen System mit niedrigem
Stromverbrauch und das dennoch vor Signalzusammenstoß schützt.
-
Nach
der vorliegenden Erfindung wird ein Datenübertragungssystem geschaffen
mit einem Sender und einem Empfänger,
wobei der Sender dazu vorgesehen ist, zu Übertragungszeitpunkten Datenbursts
zu senden und wobei die Zeitverzögerung
zwischen aufeinander folgenden Übertragungszeitpunkten
variabel ist, wobei der Sender einen ersten Ortsoszillator aufweist,
der dazu vorgesehen ist, die Zeit der Datenübertragung zu steuern und wobei der
Empfänger
einen zweiten Ortsoszillator aufweist; dadurch gekennzeichnet, dass
der Sender weiterhin einen ersten pseudobeliebigen Sequenzgenerator aufweist,
der dazu vorgesehen ist, die Zeitverzögerung zwischen aufeinander
folgenden Zeitpunkten zu bestimmen, wobei der Sender dazu vorgesehen
ist, Datenbursts mit einem Tastverhältnis von weniger als 5% zu
senden, und wobei der Empfänger
weiterhin einen zweiten pseudobeliebigen Sequenzgenerator aufweist
zur Synchronisation zu dem ersten pseudobeliebigen Sequenzgenerator,
und wobei dem Empfänger
im Wesentlichen nur in der Zeit entsprechend dem Timing der Datenbursts
Energie zugeführt
wird.
-
Die
vorliegende Erfindung schafft ein pseudobeliebiges Timing von Datenbursts
zur Vermeidung vielfacher Zusammenstöße zwischen benachbarten Systemen,
die auf derselben Wellenlänge
arbeiten. Dies vermeidet den Bedarf, ein kompliziertes Multiplex-System
zu implementieren. Der Empfänger wird
derart gesteuert, dass er nur zu der Zeit der Datenbursts (und gerade
davor) Energie verbraucht. Die pseudobeliebige Sequenz ist vorhersagbar,
so dass der Empfänger
bestimmen kann, wann künftige Datenbursts
eintreffen werden.
-
Vorzugsweise
wird der Sender vorgesehen zum Senden von datenbursts mit einem
Tastverhältnis
von weniger als 1%.
-
Der
Sender und der Empfänger
umfassen je eine Energiequelle, die eine nicht neu aufladbare Batterie
enthält.
Dies wird ermöglicht
durch die Energie-Effizienz des Systems.
-
Jeder
Datenburst kann einen Kopfteil und einen Datenteil enthalten und
der Kopfteil für
einen Subsatz der Datenbursts umfasst eine Sequenz, die für den Kopf
einzigartig ist, wodurch der Empfänger die Möglichkeit bekommt, Bitzeitinformation
zu erhalten. Der Kopfteil für
einen Subsatz der Datenbursts kann auch Daten enthalten, welche
die Zeitperiode bis an die nächste
Nachricht definieren. Dies ermöglicht,
dass die pseudobeliebige Sequenzgeneratoren synchronisiert werden.
-
Der
Sender kann vorgesehen sein zur Befestigung an einem Schuh und umfasst
dann einen Beschleunigungsmesser und eine Verarbeitungseinheit, wobei
die Verarbeitungseinheit die detektierte Beschleunigung über die
Zeit integriert, und zwar zum Erhalten augenblicklicher Geschwindigkeitswerte, die
in den Datenbursts übertragen
werden. Der Empfänger
kann vorgesehen sein um an dem Puls des Benutzers des Systems getragen
zu werden. Dies ermöglicht
es, dass ein Geschwindigkeitsüberwachungssystem
für Jogger
oder Radfahrer implementiert wird.
-
Jeder
Ortsoszillator umfasst vorzugsweise einen 32768 Hz Quarzoszillator,
der als preisgünstiges
Armbanduhrelement verfügbar
ist.
-
Ausführungsbeispiele
der Erfindung sind in der Zeichnung dargestellt und werden im Folgenden näher beschrieben.
Es zeigen:
-
1 ein
Datenübertragungssystem
nach der vorliegenden Erfindung,
-
2 im
Allgemeinen die Nachrichtenstruktur, wie diese in dem Übertragungssystem
nach der vorliegenden Erfindung verwendet wird,
-
3A eine
spezifische "statische" Nachrichtenstruktur,
wie diese in dem Übertragungssystem
nach der vorliegenden Erfindung verwendet wird,
-
3B eine
spezifische "dynamische" Nachrichtenstruktur,
wie diese in dem Übertragungssystem
nach der vorliegenden Erfindung verwendet wird,
-
4 ein
Jogging-Schuhsystem, wobei das Übertragungssystem
nach der vorliegenden Erfindung angewandt wird.
-
1 zeigt
ein Datenübertragungssystem nach
der vorliegenden Erfindung. Das System umfasst einen Sender 10 und
einen Empfänger 12.
Der Sender 10 umfasst einen Prozessor 14, der
Signale von einem Taktgeber 15 in Form eines Quarzuhr-Oszillators mit
einer Frequenz von 32768 Hz empfängt, und
einen pseudobeliebigen Sequenzgenerator 16 (der ein Teil
des Prozessors 14 sein kann) in Form eines Rückkopplungsschieberegisters
maximaler Länge.
Der Sender umfasst ebenfalls eine nicht wieder aufladbare Batterie 18,
und eine Funkfrequenzsendereinheit 20. Der pseudobeliebige
Generator 16 steuert die Zeitverzögerung zwischen aufeinander folgenden Übertragungsinstanzen
und der Ortsoszillator 15 schafft ein Bittaktsignal.
-
Der
Empfänger 12 umfasst
einen entsprechenden pseudobeliebigen Signalgenerator 22 und einen
Ortsoszillator 24, einen Prozessor 26, eine Empfangseinheit 28 und
eine Wiedergabeanordnung 30. Der Empfänger umfasst ebenfalls eine
nicht wieder aufladbare Batterie 32.
-
Die
Wirkungsweise des Systems wird nachstehend detailliert beschrieben,
und zwar anhand einer bestimmten Verwendung des Systems in einem Lauf-
oder Wanderschuh mit einem Sender zum Aussenden von Geschwindigkeits-
und/oder Abstandsdaten zu einem Armbandempfänger. Dieses System ermöglicht es,
dass ein Läufer
die Geschwindigkeit bei Langstreckenläufen in Schritte ausdrücken kann. Bei
diesem System ist es notwendig, dass die Geschwindigkeit für den Benutzer
oft aktualisiert wird mit einer genauen Abstandsberechnung, sogar, wenn
bestimmte Geschwindigkeitssignale nicht erfolgreich empfangen werden.
Das System soll auch funktionieren, wenn es andere Benutzer in der
Nähe gibt,
und soll preisgünstig
sein mit einer guten Lebensdauer einer nicht wieder aufladbaren
Batterie.
-
Um
diese Aufgaben zu erfüllen
werden kurze Nachrichten über
das Funkgerät
gesendet, das möglichst
kurze Zeit aktiv ist, indem in dem Empfänger eine bekannte Eintreffzeit
eintreffender Nachrichten bestimmt wird. Um einen Zusammenstoß zwischen Systemen
zu vermeiden, wenn auf derselben Übertragungsfrequenz gearbeitet
wird, senden verschiedene Systeme Daten zu verschiedenen Zeitintervallen.
-
Die
Kommunikation zwischen dem Sender und dem Empfänger startet mit einer einmaligen
Registrierung "Installation". Dies schafft eine
Sender ID, die dem Empfänger
mitgeteilt wird, oder der Empfänger
wird auf eine andere Art und Weise über einen voreingestellten
Sender informiert.
-
Während einer
Session erwirbt der Empfänger
die Sender ID und synchronisiert den pseudobeliebigen Sequenzgenerator.
Während
der Session werden kurze Nachrichten gesendet, beispielsweise etwa
jede Sekunde eine Nachricht von 10 ms. Die Nach richt enthält Geschwindigkeitsdaten,
ermittelt durch einen Beschleunigungsmesser, und durch den Prozessor
in augenblickliche Geschwindigkeit umgewandelt. Die Sequenz ermöglicht es,
dass der Empfänger
Schritt hält
mit dem Sender, sogar wenn Nachrichten verloren gehen.
-
Die "Nachrichten" werden etwa einmal
in der Sekunde mit einer Bitrate von 2730 Bits in der Sekunde übertragen,
d.h. jedes Bit hat eine Dauer gleich 12 Zyklen des Bezugsuhrkristalls
von 32 kHz. Ein typischer Mikrocontroller teilt die Bezugstakteingangsrate
durch 4 um jeden Instruktionszyklus zu geben. In diesem Fall hat
jedes Bit eine Dauer von 3 Instruktionszyklen, was praktisch gesehen
das Minimum ist um Daten zu senden oder zu empfangen unter Anwendung
eines Einbettungsprogrammcodes wenn der Mikrocontroller durch ein
Uhrkristall getaktet wird.
-
Das Übertragungsverfahren
kann einfach "On-Off
Keying" (OOK) Amplitudenmodulation
verwenden, wobei der HF-Träger
verwendet wird um binär "1" darzustellen und das Fehlen des Trägers um binär "0" darzustellen.
-
Die
Nachrichten sind strukturiert, wie in 2 dargestellt,
wobei nur die durch fette Linien umgebenen Teile in allen Nachrichten
vorhanden sind.
-
Der
(lange) RUN-IN besteht aus einer Reihe binärer "1"en
und ist nur in jeder 4. Nachricht vorhanden um die mittlere Übertragungszeit
zu reduzieren, wodurch Zeit frei gemacht wird für mehrere Schuhe. Der lange
RIN-IN hilft bei der Identifikation des "framing" Musters und markiert die Nachrichten,
welche die Zeitdaten (variable Zeitverzögerung bis an die nächste Nachricht)
enthalten. Die Sequenz aufeinander folgender "1"en
in der Kombination von "RUN-IN" und "Framing" Muster ist länger als
in den normalen Daten auftritt, so dass dieser RUN-IN ein einzigartiges
Muster definiert. Deswegen kann, wenn die Position des Framingimpulses
nicht genau bekannt ist (innerhalb einer einigen Bitperiode), diese
in jeder 4. Nachricht identifiziert werden, weil sie unmittelbar dem
langen Run-In folgt. Die drei dazwischen liegenden Nachrichten haben
nur einen kurzen Run-In
(typischerweise 2 Bits), enthalten in dem Framingmuster. Die Länge des
langen Run-Ins wird durch Eintritt in eine Zählschleife, und zwar jeweils,
wenn eine "1" detektiert wird,
wobei das Zählen
endet, wenn eine "0" danach detektiert
wird. Auf alternative Weise kann ein Block linearen Codes folgen
und die Progression durch den Code vor der Detektion einer "0" wird benutzt um die Länge des
Run-Ins anzugeben.
-
Das
FRAMING-Muster wird verwendet um die empfangende Logik vorzubereiten
und zu synchronisieren (innerhalb des Mokrocontrollers der Armbandeinheit),
die bereit ist, aufeinander folgende Nachrichtendaten zu akzeptieren.
Wenn kombiniert mit dem langen Rin-In bildet dieses Muster ein auf einfache
Art und Weise wieder erkennbares einzigartiges Muster von Bits.
-
Jeder
DATENBLOCK enthält
ein Halbbyte (4 Bits) an Daten aber dies wird zwecks Fehlerdetektion auf
6 Bits erweitert, und zwar zum Reduzieren der maximalen Anzahl aufeinander
folgender identischer Bits, und zum Balancieren der Anzahl "0"en und "1"en.
Es ist erwünscht,
die Anzahl aufeinander folgender identischer Bits aus mehreren Gründen zu begrenzen,
beispielsweise zum Fördern
der Daten-Slicing in den HF-Empfängerschaltungen.
Wenn aber die Grenze für
die Anzahl wiederholter Bits kürzer
gesetzt wird, müssen
mehr "redundante" Bits hinzugefügt werden
und dies begrenzt den Betrag an Daten, die getragen werden können, bei
einer bestimmten Datenrate und Übertragungszeit.
-
So
können
beispielsweise zwei Bits zu jedem Halbbyte von 4 Bits hinzugefügt werden,
was den längsten "Run" auf 4 Bits begrenzen
kann. Dies gibt auch einen bestimmten Datenpegel an "Fehlerfangen", weil bestimmte
Muster von Datenbits nicht gültig
sind.
-
Eine
ausgewuchtete Anzahl "0"en und "1"en kann den "Daten-Slicing-Prozess fördern. Außerdem kann, wenn jeder codierte
Block die gleiche Anzahl "1"en hat, ein einziger
Bitfehler nur einen nicht gültigen
Code erzeugen und der Fehler kann detektiert werden. Dieser Prozess
hat Charakteristiken entsprechend dem vorhergehenden Prozess der
Begrenzung der Länge
der "Runs" und das Codierungsschema
kann derart gewählt
werden, dass eine geeignete Darstellung der beiden Charakteristiken
erzielt wird.
-
Es
gibt zwanzig 6-Bit Muster, die drei "1"en und
drei "0"en enthalten und
es sind nur 16 erforderlich um alle möglichen Daten-Nibbles zu codieren. Der
längste
Weg desselben Bits innerhalb eines Codes muss 3 sein, wenn aber
zwei Codes nacheinander übertragen
werden, kann an ihrem Knotenpunkt ein längerer Lauf auftreten. Zwei
der Muster starten (und enden) mit drei identischen Bits, so dass
durch Eliminierung derselben das Auftreten von Läufen von 6 oder 5 identischen
Bits vermieden wird. Es ist nicht möglich, die Möglichkeit
von Läufen
von 4, die auftreten, völlig
zu eliminieren, aber zwei Muster beginnen und enden mit Läufen zweier
identischer Bits, so dass, dadurch, dass sie eliminiert werden,
das Auftreten von Läufen
von vier identischen Bits reduziert wird.
-
Die
selektierten 16 Bit Muster können
unter Verwendung einer Nachschlagtabelle mit 16 Eingängen codiert
werden. Es gibt mehrere Möglichkeiten die
6 Bit Wörter
in dem Empfänger
zu decodieren, von denen eine Möglichkeit
ganz einfach die Verwendung einer weiteren Nachschlagtabelle ist.
Aber je nach dem angewandten Codierungsschema kann Decodierung unter
Verwendung logischer Elemente möglich
sein.
-
Hinter
den drei Datenblöcken
sind drei etwaige (nicht geschützte)
FRLAG Bits vorhanden, die zur zusätzlichen Steuerung oder zum
Datentransport verwendet werden können.
-
Die
binären
Bitfolgen der Nachrichten werden in Reihenfolge von "Hoch" Bit zuerst bis "Niedrig" Bit zuletzt. Die
am wenigsten signifikanten Bits werden folglich als letzte übertragen,
wobei es eine größere Gefahr
gibt, dass Datenfehler auftreten (beispielsweise ein teilweiser "Zusammenstoß" mit einer Nachricht
von einem anderen Sender).
-
Die
Nachrichten in den Datenblöcken
enthalten "Geschwindigkeitsdaten" und "Abstandsdaten", aber das sind keine
Absolutwerte, weil sie keine Kalibrierung für den Benutzer enthalten, die
in der Armbandeinheit (dem Empfänger)
durchgeführt
werden kann, wobei der Benutzer imstande ist, den erforderlichen
Korrekturfaktor viel mehr auf herkömmliche Art und Weise einzugeben.
Es kann einen einfachen Beschleunigungsmesser in dem Schuh geben
und die Kalibrierung soll verschiedene Gänge verschiedener Benutzer
berücksichtigen.
Es kann auch notwendig sein, mehr als nur einen Beschleunigungsmesser
zu verwenden.
-
Wenn
der Schuh verwendet wird bestehen die "Geschwindigkeitsdaten" aus typischerweise
8 Bits und müssen
in jeder Nachricht übertragen
werden (d.h. wenigstens einmal je Sekunde). Aber die gesamte "Systemhaushaltung" erfordert viel mehr
als 8 Bits und würde
nicht auf effiziente Art und Weise die verfügbare Funk- und Verarbeitungsbandbreite
verwenden um all diese Daten in jeder Nachricht zu übertragen.
Die Haushaltungsdaten ändern
sich mit einer niedrigen Geschwindigkeit, wenn überhaupt, so dass diese zum
Bilden einer "Gruppe" von Nachrichten
seriell über
eine Anzahl aufeinander folgender Nachrichten verteilt werden können. Deswegen
werden die Nachrichten in Vierer-Gruppen gegliedert, wobei verschiedene
Haushaltungsdaten in jeder Nachricht enthalten sind. Die erste Nachricht
in jeder Gruppe kann durch den langen Einlauf aufeinander folgender
binärer "1"en identifiziert werden.
-
Sogar
verteilt über
vier Nachrichten würden die
erforderlichen Haushaltungsdaten dennoch die Anzahl Bits übersteigen,
die für
die "echte" Datennutzlast von
Geschwindigkeitsdaten in jeder Nachricht verwendet werden, so dass
die Haushaltung über
eine Anzahl dieser Gruppen von 4 Nachrichten weiter verteilt werden,
beispielsweise über
3 oder 4 derartige Gruppen, um einen totalen "Rahmen" von 12 oder 16 Nachrichten zu geben.
-
Wenn
die Schuh-und-Armbandeinheit beim Anfang jeder Session eingeschaltet
wird, ist es notwendig, alle Haushaltungsdaten zu übertragen,
bevor die Wiedergabeanordnung der Armbandeinheit voll operationell
und einwandfrei sein kann. Unmittelbar nach dem "Einschalten" gibt es aber keine "Geschwindigkeitsdaten", die übertragen
werden sollen. Deswegen können
zu dieser Zeit die Haushaltungsdaten die Geschwindigkeitsdaten in
allen Nachrichten ersetzen und können
auf diese Weise in einer einzigen Gruppe von vier Nachrichten untergebracht werden,
damit die Anforderungszeit reduziert wird.
-
Auf
diese Art und Weise gibt es zwei verschiedene Typen Nachrichtenformat,
einen für
die normale "Bewegungs"-Mode des Schuhs
und die andere "statische" Mode, die optimiert
ist, damit die Armbandeinheit die richtigen Schuh-Übertragungen und
alle aktuellen Daten/Zustandsinformationen schnell "Anfordern" kann. Weiterhin
kann, wie nachstehend beschrieben, dieses Timing abhängig sein von
der Schuh-ID, so dass es wichtig ist, für die "Registrierung" (das erste Mal, dass eine Armbandeinheit
mit dem betreffenden Schuh assoziiert wird) dass die Übertragung
des "Feedback Shift
Register" (FSR)
und der erforderlichen ID in einer einzigen Nachricht erreicht werden
kann.
-
Im
normalen Betrieb tragen, wenn Geschwindigkeitsdaten übertragen
werden müssen, zwei
Nibbles die Geschwindigkeitsinformation und ein Nibble erledigt
die "Haushaltung", verteilt über den
ganzen Rahmen von 12 (oder 16) aufeinander folgenden Nachrichten.
Wenn es während
der "Anforderungs"-Stufe vor dem Laufen
oder Gehen, oder nachdem die Aktivität geendet hat, keine Geschwindigkeitsdaten
gibt, können
die drei Nibbles Haushaltungsdaten übertragen, was in einer Folge
von vier aufeinander folgenden Nachrichten komplettiert werden kann.
Die Struktur dieser Nachrichten ist in 3 dargestellt.
-
3A zeigt
die "statische" Nachrichtenstruktur.
In diesem Fall umfasst die erste Nachricht (die identifiziert werden
kann, weil sie dem langen "Einlauf" folgt) die 6 Bits
des ersten FSR-Codes sowie die vier Adressbits des Schuhs, die verwendet werden
zum Aktualisieren der FSR-Sequenz (wie unten beschrieben). Sie umfasst
auch den Merker um anzugeben, dass es eine statische Nachricht (M
= 1) ist. Die Information in der ersten Nachricht ermöglicht es,
dass das nachfolgende Nachrichtentiming bestimmt wird, und auch
die vier Bits der Adressendaten sind eine Hilfe dabei, einigermaßen zu bestimmen,
dass der richtige Schuh empfangen wird. Die nachfolgenden Nachrichten
enthalten den restlichen Teil der Schuhadresse, der Abstandsdaten
und mehrerer anderer Daten. In 3A ist
Fn ein Zwei-Bit-Merker vom Frame-Typ oder von der Frame-Nummer (beispielsweise
der Nachrichtennummer 1 bis 3 innerhalb des größeren Frames), M ist ein Merker
zum Identifizieren eines statischen oder dynamischen Nachrichtentyps,
FSR m–n
sind Bits m bis n vom "Feedback
Shift Register",
Adresse m–n
sind Bits m bis n von der Schuhadresse und Abstands m–n sind
Bits m bis n von einem akkumulierten Abstandsregister. Die Abstandsdaten
können
nur alle 12-Nachriuchtenframes aktualisiert werden. V niedrig ist
ein etwaiger "Low
Batterie Voltage" Merker.
-
3B zeigt
die "dynamische" Nachrichtenstruktur.
In dem Fall sind die 8 Bit Geschwindigkeitsdaten für jede Nachricht
in dem zweiten und dritten Nibble enthalten, und das erste Nibble
wird nur für
die Adresse, die FSR Daten und Abstandsberechnungen verwendet. Zusätzliche
dargestellte gemischte Bits enthalten R/W um zu identifizieren,
ob der Benutzer geht oder läuft,
und Volts 3–0
kann die Schuhbatteriespannung angeben. Es gibt selbstverständlich andere
diagnostische Funktionsdaten, die Übertragen werden können.
-
Wenn
die oben stehenden Parameter mit je 4 Bits für das erweiterte Run-in und
Framing und einen Hilfsmerker vorausgesetzt werden, ist die längste Nachricht
(wobei der Merker A aktiv ist) 27 Bits mit 3 aufeinander folgenden
Nachrichten von 23 Bits. Auf diese Art und Weise ist die mittlere
Nachrichtenlänge 24
Bits, die eine Dauer von etwa 8,8 Millisekunden hat. Wenn die beiden
Hilfsmerker auf "1" gesetzt sind, ist
die mittlere Nachrichtendauer etwa 9,15 ms.
-
Wegen
der sehr begrenzten Energiemittel (Batterie), die in der Armbandeinheit
verfügbar
sind, ist es unwichtig, dass der HF-Empfänger möglichst kurze Zeit betrieben
wird. Deswegen soll der Controller der Armbandeinheit imstande sein,
vorherzusagen, wann aufeinander folgende Nachrichten gesendet werden,
wenn eine gültige
Nachricht einmal empfangen worden ist. Auf diese Art und Weise enthalten die
Schuh-Einheit und die Armband-Einheit genaue Zeitbezugswerte ("Watch Crystals"), so dass Zeitfehler
nur sehr langsam akkumulieren. Dies ist besonders wichtig, da alle
Nachrichten nicht ein "einzigartiges" Datenframingmuster
enthalten, so dass dies innerhalb eines definierten Fensters für die zwischen liegenden
Nachrichten "gefunden" werden muss. Auch
enthält
nicht jede Nachricht die ganzen Adressendaten, so dass die Hauptbewertung,
dass jede einzelne Nachricht von dem erforderlichen Schuh herrührt, ist,
dass die Nachricht in dem erwarteten Zeitschlitz liegt.
-
Die
Zielaktualisierungsrate für
Information, die an der Armbandeinheit wiedergegeben wird, beträgt einmal
in der Sekunde, so dass Nachrichten mit einem mittleren Zwischenraum
etwas kleiner als diese Zeit, übertragen
werden. Eine höhere
Wiederholungsrate ist selbstverständlich erwünscht, aber für eine bestimmte
Datenrate und Nachrichtenlänge (Dauer)
würde dies
auf Kosten der Begrenzung der Anzahl Benutzer gehen, die sich das
verfügbare Funkband
teilen könnten
(durch Erzeugung einer unakzeptierbaren Anzahl Nachrichtenzusammenstöße).
-
Wie
oben erwähnt,
wird zwischen Nachrichten eine variable "beliebige" Verzögerung mit einer Länge zwischen
750 ms und einer Sekunde angewandt, weil wenn der Nachrichtenzwischenraum
auf eine konstante feste Zeit eingestellt wird, dann, wenn die Nachrichten
von zwei Schuhen zusammenstoßen,
nachfolgende Nachrichten auch zusammenstoßen werden. Der Raum zwischen Übertragungen
ist auf 16 mögliche
genaue Werte begrenzt (die durch 4 Datenbits definiert werden können) und
dieser Datenwert wird in allen "Long
Run-in"-Nachrichten
getragen, die für
die Ausgangs-"Anforderung" des Datenstroms
verwendet werden. Dies an sich würde aber
nicht ausreichen, weil alle Nachrichten Zeitverzögerungsdaten haben sollten.
Auch eine einzelne "verloren
gegangene" Nachricht
würde "die Kette zerbrechen", so dass die Armbandeinheit
nicht wissen würde,
wann sie den HF-Empfänger
für nachfolgenden
Nachrichten einschalten soll. Auf diese Art und Weise ist die Folge
von Zeitverzögerungen
zwischen Nachrichten nicht ganz beliebig, sondern "pseudobeliebig" und die Schuh- und
Armbandeinheit kann dasselbe Verfahren anwenden zum Berechnen aufeinander
folgender Verzögerungen.
-
Die "pseudobeliebige" Zeitverzögerung wird aus
einem "Maximal Length
Feedback Shift Register" berechnet,
was auf einfache Art und Weise durch Software inner halb des Mikrocontrollers
implementiert werden kann. Jeder nachfolgende Zustand wird logischerweise
aus dem vorhergehenden berechnet, sobald die zwei FSR Zählwörter in
der Schuh- und in der Armbandeinheit synchronisiert sind, können sie für alle nachfolgenden
Zählzustände miteinander verriegelt
bleiben. Weiterhin, wenn die FSRs miteinander verriegelt sind, kann
die Empfängerlogik
die Datenwerte als eine zusätzliche "Adressenkontrolle" verwenden um zu überprüfen, ob
jede betreffende Nachricht von dem richtigen Schuh übertragen
wird.
-
Maximallängenrückkopplungsschieberegister
(ML-FSR) können
in jede beliebige Länge
aufgeteilt werden, obschon einige (beispielsweise eine Länge von
8 Bits) relativ komplexe logische Vorgänge erfordern. Eine einfache
Implementierung ist, das "Exklusiv-ODER" nur der letzten
zwei Bits des FSRs bei jeder Verschiebung zurückzukoppeln. Die ergibt keine
Maximallängensequenzen
mit allen Längen von
FSR, aber die nachfolgenden Längen
sind praktisch: 2, 3, 4, 6, 7, 15 und 22.
-
Bevor
der "Anforderungsprozess" beendet werden kann,
(wobei der Empfänger
vorbereitet wird um von dem Sender zu empfangen), muss der Zustand
aller Bits in dem FSR als Teil der "Haushaltungsdaten" übertragen
werden. Wenn eine Vielzahl Bits benutzt werden, dann kann entweder
die Anforderung eine lange Zeit dauern, oder jede Nachricht soll
einen außergewöhnlichen
Betrag an "unproduktiven" Daten tragen. Eine
Länge von
6 Bits ist für
diese spezielle Applikation selektiert worden, obschon dies eine
ziemlich "beliebige" Sequenz erzeugt.
Zusätzliche
Techniken können
aber angewandt werden um zu vermeiden, dass zwei Schuhe, mit derselben
Sequenz von "beliebigen" Codes synchron arbeiten.
-
Eine
Möglichkeit
ist, die 4 Bits, die dem FSR für
jede Nachricht mit den am wenigsten signifikanten Bits der Adresse
des Schuhs entnommen worden sind, zu "XOR"en,
bevor sie zum Definieren der Nachrichtenverzögerung verwendet werden. Deswegen
gibt es in Termen der Sequenz von Bits, die in den Nachrichten übertragen
worden sind, stattdessen, dass alle Schuhe dieselbe Sequenz von
63 Bits erzeugen (für
ein 6 Bit FSR), 16 verschiedene Sequenzen (d.h. eine Gesamtzahl
von 1008 Bits) je nach dem Adress-Nibble des Schuhs. Auf diese Art und
Weise kann die effektive Länge
des FSRs als nahezu 10 Bits betrachtet werden. Auf diese Weise sollen
vier Bits der Schuhadresse sowie des FSR-Codes übertragen werden, damit der
Empfänger
imstande ist, das Timing der nächsten
Nachricht zu berechnen. Dies erklärt die Notwendigkeit des FSR
Codes und der vier Bits der Adressendaten in der ersten Nachricht
nach 3A.
-
Eine
zweite mögliche
Technik ist, den Nachrichtenverzögerungswert
zu modifizieren (beispielsweise durch "XOR"-en
mit einem anderen Nibble der Adresse), und zwar einmal in jedem
vollen Frame von 12 (oder 16) Nachrichten. Dies modifiziert wieder die
Timing-Sequenz der Nachrichten und hilft Situationen zu vermeiden,
wenn die Übertragungen
von zwei Schuhen längere
Zeit miteinander verriegelt werden.
-
Jedes "Frame" von 4 Nachrichten
trägt 8 "Haushaltungsbits" um die Framenummer
und die Zeitverzögerung
zwischen Nachrichten zu identifizieren. In dem "statischen" Nachrichtenformat werden alle 8 Bits
in der ersten Nachricht des Frames getragen, aber in dem "dynamischen" Format sind nur
vier Haushaltungsbitstellen verfügbar,
und diese müssen die
Verzögerungszeit
zu der nächsten
Nachricht angeben. Die restlichen vier Bits werden in dem zweiten Frame übertragen,
aber dies sind dieselben Datenbits, wie auch in dem statischen Format
verwendet werden, die von dem ersten Frame übergetragen wurden.
-
Die
Verzögerung
zwischen aufeinander folgenden "Framing
Pulse Active Edges" wird
durch die unteren 4 Bits des Inhaltes eines Rückkopplungsschieberegisters
gegeben, addiert zu einem minimalen Wert von genau ¾ Sekunde
(750 ms). Der Inkrementalwert der FSR-Bits ist 1/64 Sekunde (15,625 ms)
und folglich beträgt
die maximale Verzögerung zwischen
Nachrichten 63/64 Sekunde.
-
Mit
dem "statischen" Nachrichtenformal
enthält
das erste Frame (identifiziert durch den "langen" Einlauf) alle 6 FSR Bits, so dass die
Empfänger-Software
die Nachrichtenverzögerungen
für alle
nachfolgenden Nachrichten berechnen kann (sogar wenn einige nicht
empfangen werden), bis die Adressfelder die Brauchbarkeit der Nachrichten
bestätigen
oder zurückweisen.
Mit dem "dynamischen" Nachrichtenformat
muss der Empfänger
die Nachricht unmittelbar nach dem ersten detektieren um die 6 FSR
Bits zu geben, die ihn nur dann drehen können (um 4 Bits nach links)
um den nachfolgenden Nachrichten die Verzögerungszeit zu geben. Das Timing
der zweiten Nachricht gegenüber
der ersten muss durch einen Code in der ersten Nachricht gegeben
werden, da dieser nicht aus dem kompletten FSR Code hergeleitet
werden kann, der aus der ersten Nachricht in dem "dynamischen" Nachrichtenformat
nicht gänzlich empfangen
worden ist. In dem betreffenden, hier beschriebenen Beispiel kann
die Zeitverzögerung
zu der zweiten Nachricht aus den Bits 0–3 der Schuhadresse und aus
den Bits 0–3
der FSR Daten (die drehen) hergeleitet werden und diese Daten erscheinen alle
in der ersten Nachricht, wie aus 3B ersichtlich.
Wenn die zweite Nachricht empfangen worden ist, kann die Zeitverzögerung zu
der dritten und den nachfolgenden Nachrichten nicht bestimmt werden, so
dass die Software nach einem anderen Einlauf suchen muss.
-
Die
anderen zwei Bits der Zeitdaten können verwendet werden um eine
Framenummer anzugeben.
-
Die Übertragungen
von jedem Sender benutzen etwa 1% der verfügbaren "Luft-Zeit". Um die Kosten niedrig zu halten verwendet
der Schuh nicht ein Zugriffsprotokoll (d.h. er testet nicht um zu
sehen, ob etwaige andere Übertragungen
im Gange sind) und folglich "Zusammenstöße" manchmal auftreten
werden. Der Empfänger
muss eine Strategie anwenden, die einen gewissen Verlust gültiger Nachrichten
akzeptiert und die gesamte Leistung, wie die Aktualisierungsrate
der Wiedergabe der Armbandeinheit sollte "allmählich
degradieren" wenn
die Anzahl Schuhe, die sich den Übertragungskanal
teilen, zunimmt.
-
Der
Verlust einzelner Nachrichten ist nicht besonders signifikant, weil
die Empfängersoftware eine
Strategie anwenden kann um eine verloren gegangene Nachricht zu überbrücken und
eine einzelne fehlende Aktualisierung der Wiedergabe an der Armbandeinheit
soll wahrscheinlich nicht bemerkt werden. Wenn aber eine wesentliche
Anzahl aufeinander folgender Nachrichten verloren gegangen sind,
wird dies dem Benutzer klar werden und letztendlich werden sich
die kleinen Zeitfehler in dem Nachrichtenzwischenraum an dem Punkt
ansammeln, wo der Controller der Armbandeinheit die Übertragungen
von dem Schuh "verlieren" kann.
-
Wenn
das oben beschriebene Schema verwendet wird und für den Fall,
dass 20 Schuhe gleichzeitig arbeiten, gibt es eine Möglichkeit
von 1 zu 3, dass eine bestimmte Nachricht einen Zusammenstoß haben
wird, und etwa 1 zu 9, dass zwei solche Zusammenstöße nacheinander
auftreten. Ein Lauf von 8 aufeinander folgenden Zusammenstößen für einen
bestimmten Schuh würde
auf diese Weise etwa einmal zu 38 oder 1
zu 6561 auftreten, aber jeder Schuh sendet etwa jede Stunde 4000
einzelne Nachrichten, so dass unter diesen sehr "dichten" Arbeitsumständen eine Reihe von 8 Zusammenstößen etwa
jede 1,5 Stunden auftreten kann.
-
Die
gesendeten Daten enthalten im Wesentlichen Geschwindigkeitsdaten,
für die
ein 8 Bit Datenbyte übertragen
wird. Es gibt auch einen Vorteil beim Implementieren eines Merkers
um anzugeben, ob der Benutzer läuft
oder geht. Dieser Merker kann einer der "etwaigen" Merkerstellen am Ende einiger der Nachrichten
zugeordnet werden oder er kann eine der Bitstellen innerhalb des
Geschwindigkeitsbytes benutzen.
-
Die "Geschwindigkeitsdaten" werden nicht genauer
sein als sagen wir 1%, so dass es keine Notwendigkeit gibt, die
Daten mit einer besseren Auflösung
als diese zu übertragen.
Die wirkliche Geschwindigkeit kann niedriger sein als 10 km/h ("Jogging") bis über 30 km/h
(Sprinten). Gehen wird langsamer sein, kann aber dadurch erledigt
werden, dass eine andere Skalierung angewandt wird, selektiert durch
den Merker "Gehen". Eine "logarithmische" Skalierung kann
die Genauigkeit beibehalten, während
die Anzahl Datenbits begrenzt wird und eine "stückweise
lineare" Skalierung
kann zum Rechnen einfach sein.
-
Die
Adresse wird benutzt um zu gewährleisten,
dass die Armbandeinheit Nachrichten von dem richtigen Schuh empfängt. Da
der Schuh nicht einen Empfänger
hat um zu bestimmen, welche Adressen von anderen Schuhen in der
Nähe verwendet
werden, müssen
genügend
Adressen zugeordnet werden um zu gewährleisten, dass es eine geringe
Gefahr gibt, dass zwei Schuhe dieselbe Adresse haben. Eine Lösung ist,
jedem Schuh eine andere Adresse zuzuordnen, aber dies kann nur bei
der Fertigung gemacht werden und erfordert die Verwendung eines nur
einmal programmierbaren Speichers in dem Mikrocontroller des Schuhs.
Auch wenn eine größere Anzahl
Schuhe hergestellt wird, müsste
eine Vielzahl von Bits innerhalb des Protokolls übertragen werden.
-
Wenn
es nicht praktisch ist, die Adressen in einem nur einmal programmierbaren
OTP-Speicher zu speichern (beispielsweise weil ein maskierter-ROM-Prozessor
verwendet wird), kann eine "beliebige" Anzahl von dem Mikrocontroller
erzeugt werden, wenn zunächst
die Batterie eingeführt
wird. In beiden Fällen
wird die Armbandeinheit im Allgemeinen vorgesehen sein um die Adresse
des Schuhs in dem "Lern"-Prozess zu lernen,
wenn es keine weiteren "arbeitenden" Schuhe in dem HF-Bereich
gibt.
-
Die
ABSTAND-Daten sind nicht gemeint, um "sofort" die Abstandsauslesung für die Armbandeinheit
zu schaffen (die sie selber aus den Geschwindigkeits- und den Zeitdaten
berechnen kann). Dies gibt einen gesammelten Abstand für Langzeitkontrolle, wenn
beispielsweise eine Vielzahl von Geschwindigkeitswerten über die Übertragungsver bindung
nicht empfangen worden sind. Da ein komplettes Datenframe wenigstens
10 Sekunden dauert (drei Blöcke von
4 Nachrichten, jede Nachricht in einem Abstand von wenigstens 0,75
s von einer anderen Nachricht), gibt es wenig Raum für eine Auflösung besser
als 100 m. Mit einem am wenigsten signifikanten Bit von 100 m können 12
Bits bis zu 400 km darstellen, was für jede beliebige Lauf- oder
Gehsession ausreichen wird. Wenn aber der Schuh still steht, gibt
es eine gute Gelegenheit an beiden Enden des Abstandsdatenwortes
um genauere Daten zu senden. Vier Bits an dem "niedrigen" Ende würden auf etwa 6 m auflösen, was
für kurze
Aktivitäten-Bursts
(beispielsweise Sprint) relevant sein kann. Ein weiterer Nibble
an dem "hohen" Ende würde den
Bereich auf etwa 6500 km erweitern. Was vielleicht einen etwaigen
Laufbereich über
die typische Lebensdauer der Batterie des Senders darstellt, wie
das "Odometer" in einem Kraftwagen.
-
Ein
Merker "Batterie
fast leer" kann
einer der "freien" Merkerstellen am
Ende einiger der Datennachrichten zugeordnet werden. Über eine
Zeitperiode kann dies überprüft werden,
so dass kein Fehlerschutz erforderlich ist. Ein weiterer Vorteil
der Lage am Ende der Nachricht und "aktiv hoch" (d.h. "1" bedeutet
Batterie fast leer) ist, dass mit OOK Modulation die "normale" Bedingung (d.h. "Batterie gut") eine etwas kürzere Nachricht
ergibt.
-
Wenn
die Armbandeinheit für
eine Aktivitätssession "aufgestartet" wird, muss sie mit
den Übertragungen
von dem Schuh verriegelt sein. Die allgemeine Priorität von Aktionen
ist:
- 1. Das Finden des Einlauf- und Framing-Musters jedes
Schuhsignals und das Auslesen der Daten;
- 2. das Identifizieren der Zeitverzögerung zu der nächsten Übertragung;
- 3. das Überprüfen (eines
Teils) der Adresse des Schuhs (falls vorhanden) und das Suchen nach einem
anderen Schuh, falls nicht richtig;
- 4. Das Fortsetzen des Empfangs von Blöcken mit Daten bis alle verfügbar sind
oder bis gefunden wird, dass ein Teil der Adresse falsch ist.
-
Wenn
der Schuh das "statische" Nachrichtenformat überträgt (d.h.
wenn er keine Geschwindigkeitsdaten enthält), dann enthält die "long Run-in" erste Nachricht
genügend
Daten um den Anforderungsprozess fortzusetzen, sogar wenn einige
nachfolgende Nachrichten "verloren" gegangen sind, beispielsweise
durch einen Zusammenstoß mit
anderen Übertragungen.
Die 4-Bit Adresse in dieser Nachricht ermöglicht auch, dass 94% der Übertragungen
von nicht richtigen Schuhen sofort zurückgewiesen werden. Um den Anforderungsprozess
zu vervollständigen
soll der Empfänger
wenigstens einen der drei anderen Nachrichtentypen empfangen. Weitere
Nachrichten können
aber nützlich
sein um die Daten völlig zu überprüfen, beispielsweise
wenn Fehler erwartet werden, oder wenn die (Abstands)Daten anders
sind als normalerweise in der Armbandeinheit gespeichert.
-
Wenn
der Schuh das "dynamische" Nachrichtenformat überträgt, gibt
es nur genügend "Haushaltungsdaten" um den Zeitspalt
zu der nächsten Nachricht
zu identifizieren, und wenn diese zweite Nachricht nicht gefunden
wird, (die den FSR-Code komplett macht), muss der Anforderungsprozess
neu gestartet werden. Dies ist ungünstig wenn ein Zusammenstoß auftritt,
aber weil die Zeitverzögerung
in der langen Run-in Nachricht "verschlüsselt" sein kann (ge-ODER-t
mit 4 Bits der Adresse des Schuhs) können in dieser Stufe etwa 94%
der "nicht richtigen" Übertragungen automatisch zurückgewiesen
werden. Wenn die Nachricht nach der langen Run-in Nachricht erfolgreich
empfangen wird, ist der ganze FSR-Inhalt bekannt, so dass der FSR
in die nächste Stufe
geschoben werden kann. Dies gibt der Armbandeinheit genügend Zeitinformation
um mit der Erwerbung fortzufahren, sogar wenn einige Nachrichten
dann verloren gehen. Sie muss aber wenigstens jeden der 12 Typen
von Nachrichtenblöcken
erfolgreich empfangen, bevor völlig
aktualisierte Daten von dem Schuh bestätigt werden.
-
Neuerwerbung
nach einer unterbrochenen Übertragungssequenz
ist anders als eine komplette Erwerbung, weil der aktuelle Inhalt
des Rückkopplungsschieberegisters
dennoch berechnet werden kann. Dies soll möglich sein, bis die Zeitbezugswerte in
dem Schuh und in der Armband um etwa eine halbe Sekunde auseinander
gegangen sind, was während
wenigstens eine oder zwei Stunden nicht auftreten soll. Auf diese
Art und Weise ist es erwünscht, dass
die Mikrocontroller in den beiden Einheiten die Berechnung des FSR-Wertes
in einer "Hintergrundmode" für diese
Zeitlänge
fortsetzen, sogar wenn der Sender oder der Empfänger nominal "abgeschaltet" ist (automatisch,
oder von dem Benutzer).
-
Je
nach der vergangenen Zeit soll die Armbandeinheit den Empfänger für ein weiteres "Fenster" einschalten, entweder
für einen
dauernden Burst oder in kurzen "Schnappschüssen" die weiter von der erwarteten
Zeitlage weggehen.
-
Auf
dieselbe Art und Weise wie für
den ganzen Erwerbungsprozess sucht der Armbandcontroller nach langen
Run-in Nachrichten. Sogar aber, wenn der Schuh das "dynamische" Nachrichtenformat überträgt, ist
der Empfänger
dennoch imstande, etwa 94% der Nachrichten von "falschen" Schuhen zurückzuweisen, weil die 4 Bits
des erwarteten FSR Inhaltes bekannt sind. Für den Fall des "statischen" Übertragungsformats ist der
erwartete Zustand von allen 12 Bits bekannt, so dass nahezu alle
nicht richtigen Übertragungen
unmittelbar zurückgewiesen werden.
Auf diese Art und Weise kann eine Neuerwerbung schneller gehen und
kann bestehen, dass Nachrichten verloren gehen, und zwar schneller
als eine komplette Erwerbung, insbesondere, wenn der Schuh sich
bereits in der "dynamischen" Mode befindet.
-
Es
ist wichtig, dass die Armbandeinheit mit dem richtigen Schuh "übereinstimmt" und folglich kann
ein spezielles Nachrichtenformat um dies zu unterstützen, vorteilhaft
sein. Die Armbandeinheit wird aber im Allgemeinen nur imstande sein,
mit einem Schuh "überein zu
stimmen", der das "statische" Nachrichtenformat überträgt (so dass
alle Adressdaten aus einer einzigen Nachricht ausgelesen werden können), weil
der Empfänger
bereits den niedrigen Nibble des Adressenfeldes kennen soll um den FSR-Inhalt
zu "entwürfeln" um imstande zu sein,
die Zeitverzögerung
bis zur nächsten
Nachricht zu berechnen.
-
Bevor
die seriellen Datenbits genau empfangen werden können, muss der Programmcode
sich selber zu den Bitübergängen synchronisieren
(und zwar unter Verwendung der Run-in- und Framing-Muster), so dass
er den Signalpegel ("0" oder "1") in der Nähe der Mitte jeder Bitstelle "liest". Im Grunde geschieht
dies durch Verwendung einer Programmschleife um zu warten, bis das
Trägersignal startet
(beispielsweise für
einen logischen Pegel "1") und danach fügt der nachfolgende
Programmcode Instruktionszyklen hinzu oder überspringt diese, je nachdem,
wann die Framing-Übergänge auftreten.
-
Wenn
(nicht nachgeregelte) Uhrkristalle verwendet werden, sollen die
Zeitbezugswerte in der Schuheinheit und in der Armbandeinheit besser
sein als 100 ppm oder 0,01%. Es kann auch praktisch sein, dass die
Armbandsoftware ihre eigene Zeitbezugswerte berechnet gegenüber denen
des Schuhs, und zwar für
eine größere Genauigkeit
während
des Erwerbungsprozesses. Nach einem Spalt gleich einer Sekunde zwischen
zwei Nachrichten, soll der Framing-Impuls innerhalb von 100 μs oder etwa ¾ einer
Bitperiode liegen. Auf diese Art und Weise soll der Empfang jeder
Nachricht möglicherweise
gegenüber
den Flanken des Framing-Impulses neu "getimed" werden, aber es könnten 5 bis 10 Nachrichten verloren
gehen, bevor es eine Gefahr gibt, dass andere Daten mit dem Framing-Impuls
ge stört
wird. Die Position der erwarteten Framing-Position für nachfolgende
Nachrichten soll erst dann aktualisiert werden, wenn die ganze Nachricht
bewertet worden ist, weil ein Zusammenstoß mit einer Nachricht von einem anderen
Schuh einen falschen Framing-Impuls schaffen könnte.
-
Nach
etwa 10 fehlenden Nachrichten gibt es eine Gefahr, dass ein Teil
der Daten mit dem Framing-Impuls gestört wird, so dass es günstig sein kann,
die Suche nach Nachrichten mit einem langen Run-In günstig sein
kann. Dies ist auch eine Hilfe beim Sparen von Energie der Batterie,
wenn das Fenster "on" des HF-Empfängers rechtzeitig
vergrößert wird.
Die maximale Zeit bevor ein kompletter Neuerwerbungsprozess anfangen
soll, ist abhängig von
der maximalen kontinuierlichen Zeit, dass der HF-Empfänger betrieben
werden soll, aber wenn dies, sagen wir, 20 ms ist, kann die Neuerwerbung etwa
1 Minute nachdem keine gültigen
Nachrichten gefunden worden sind, anfangen.
-
4 zeigt
einen Schuh 40, der mit einem Sender 10 versehen
ist, der an einer Seitenwand des Schuhs vorgesehen ist, und zwar
parallel zu der Sohle des Schuhs. Der Sender umfasst einen Beschleunigungsmesser,
der den horizontalen Anteil der Beschleunigung misst, der die Einheit
ausgesetzt ist. Diese Daten werden von dem Prozessor 14 integriert um
die Geschwindigkeitsdaten zu erzeugen und weiter integriert und
Abstandsdaten zu erzeugen, und zwar zur Übertragung zu dem Empfänger 12.
Der Empfänger 12 ist
in Form einer als Armband ausgebildeten Wiedergabeanordnung.
-
Die
vorliegende Erfindung ist anhand einer bestimmten Applikation beschrieben
worden. Die Grundlagen können
aber auch auf ein anderes Datenübertragungssystem
zur Verwendung in Applikationen angewandt werden, wobei kurze aber
oft ausgesendete Datenimpulse mit geringem Stromverbrauch übertragen
werden.
-
Es
wurde eine einzige spezifische Implementierung detailliert beschrieben.
Es können
aber mehrere Parameter geändert
werden, und dies dürfte dem
Fachmann einleuchten. So gibt es beispielsweise mehrere Techniken
zum Erzeugen pseudobeliebiger Sequenzen und verschiedene Grade der
Beliebigkeit werden unter verschiedenen Umständen geeignet sein. Es wurde
ein Uhrkristall als preisgünstige Zeiteinheit
selektiert, obschon auch andere bekannte Zeitschaltungen verwendet
werden können.
-
Text in der
Zeichnung
-
2
-
-
3A
-
- Nachricht 1
- Adresse Abstand Frei
-
3B
-
- Nachricht Adresse Geschwindigkeit
- Abstand