Ortung innerhalb 100m per Funk möglich?

[oberallgeier]

.. dass meine Idee mit 2 Empfangspunkten Mumpiz ist .. Ich brauche also mindestens 3 Empfänger mir fixer Position ..

Stimmt. Vor etlicher Zeit fühlte ich mich bemüßigt dazu etwas zu schreiben, mit Skizze und Arbeitsanweisung, aber ohne mathematisch formulierte Rechenvorschrift. Allerdings gibt es zur Aussage "mindestens 3 Empfänger mit fixer Position" die eine oder andere Einschränkung/Notwendigkeit. Steht dort auch, siehe dort unter P..S.

Manchmal denke ich, träumerisch, an so ne Art Sekundärradar mit - für uns sinnvoll machbarer - Laufzeitmessung. Bestehend aus einem Funksender und drei UltraschallEMPFÄNGER am beweglichen Objekt und drei Baken mit Funkempfänger und akustischer Ausgabe. Der Funker funkt ein Ping und die Baken antworten akustisch. Aus der Laufzeit der Ultraschall-Antwort kann man dann relativ genau mittels Rückwärtseinschnitt den Standort im Bezug auf die Baken bestimmen. Die Laufzeit des Funksignals sollte im Bereich weniger Meter vernachlässigbar sein, die Verarbeitungsgeschwindigkeit in der Bake hoffentlich auch, die Temperaturunterschiede im Raumabschnitt müssen vernachlässigt werden (nicht messbar ohne dollen Aufwand). Dann bleibt die Rechnung auf ein paar Zentimeter genau - aber 1 GHz ist für Mathematik mit transzendenten Funktionen schon ein starkes Wort.

Natürlich ginge das auch umgekehrt - Ultraschall-Ping vom bewegten Objekt und Funkantwort - nur ein Ping. Die Ortsberechnung aus den Laufzeiten wäre dann die gleiche.

[PICture]

Der Funker funkt ein Ping und die Baken antworten akustisch.

Genau, das ist für mich machbar !

Ich kann mir Messungen von wenigen ns mit einem µC gar nicht vorstellen.

[Thomas$]

Probiers mal mit gemütlichkeit, Schall ist deutlich langsamer. Da kannst du auch erstmal mit den gleichen Verfahren testen.

[i_make_it]

Jetzt stellt sich allerdings die Frage welches Ultraschall System bei 100 Metern und höchstwarscheinlich im Freien und in Luft, entsprechend Fehlerfrei funktioniert.
So das weder Störgeräuche noch Sekundär Reflektionen Probleme bereiten.
Man kann ja nicht einfach US beliebig aufdrehen, nur weil man ihn bewusst nicht wahrnimmt.
Ich habe da so eine schöne Bauanleitung in einem Buch von Günter Wahl für eine Ultraschall Pistole die Angstzutände und psychotische Symptome verursachen soll.

[Cysign]

Ich denke, Ultraschall ist in einer nicht genauestens definierten Fläche nicht realisierbar. Schall hätte natürlich den Vorteil, dass er wesentlich langsamer ist. Aber ich denke, bei einem bewegten Objekt (Neigungen) und möglichen Hindernissen im Weg (Baum, Hügel...) ist das nicht so zielführend.
Wenn man dann sein Modell an einen anderen Ort mitnimmt, müsste man dann ja akustische Messungen in der neuen Umgebung anstellen und einen Algorythmus entwickeln, der dann aus den sich neu ergebenden Reflektionen den Standort ermittelt.

Oben fiel auch mal das Wort DSP.
Ich hab gestern einfach mal nach "Getting started DSP" gesucht und das wirkt auf mich grade erstmal wie ein Schloss mit tausend Siegeln.
Um da einzusteigen werden dann Eval-Boards in der 200€-Klasse empfohlen. Aber ich bin mir noch nicht sicher, wie ich möglichst schnell rausfinden kann, ob ein DSP überhaupt geeignet ist. Beim Raspberry konnte ich einfach mit den Suchbegriffen GPIO und Mhz schon ziemlich schnell die Limitierungen finden.

Und dann stellt sich mir noch die Frage: Was macht einen DSP so anderst als z.B. einen ARM.
Klar, er ist auf eine Aufgabe ausgelegt. Aber das ist ja bei ARM gewissermaßen auch gegeben. Die Hersteller kaufen die Lizenz für den Kern und erweitern ihn um die gewünschten Funktionen.

Aber wichtiger ist für mich auch aus Sicht der Leute, die sich schonmal mit DSP befasst haben, die Frage, ob und in welchem Preisrahmen soetwas realisierbar wäre.
Bewege ich mich da im Bereich einiger hundert Euro oder eher im Bereich der zwhntausend Euro?

Angenommen ich habe dann einen Chip, der schnell genug ist, um das Signal auszuwerden, dann stellt sich mir noch die Frage: kann ich überhaupt die Zeitbasis meiner Komponenten genau genug synchronisieren?
Ein RTC-Modul wird nicht so hoch auflösend sein, dass das funktioniert. Also müsste ich mit dem Wissen um die bekannten Entfernungen zwischen meinen Empfängern ein Signal von zwei Empfängern zum dritten senden, die Laufzeit rausrechnen und anschließend damit dann die Zeit synchronisieren.
Oder das Ganze evtl. über DCF77 synchronisieren? Wenn das Zeitsignal z.B. von Satelliten ausgegeben wird, dürfte die Zeit zum Eintreffen bei meinem DSP annähernd die selbe sein, wenn der Satellit etwa senkrecht über meinem Aufbau fliegt. Andererseits, wenn er einen sehr flachen Winkel aufweist, hätte ich wieder meine Laufzeitverzögerung.

So langsam begreif ich die Komplexität der Thematik, aber das macht es nicht weniger interessant

[Mxt]

Ich werde mich wohl mal mit den TI DSPs befassen, sobald sich da die Gelegenheit bietet.

Letzten Freitag ist endlich die neueste Auflage vom Beagleboard in Produktion gegangen, mal sehen wann und wo das bei den Händlern auftaucht. Soll in den USA 259 Dollar kosten
http://beagleboard.org/x15
und

Will I be able to program the C66x DSPs?

Yes, there is a free C/C++ compiler from Texas Instruments and support in the mainline of the open source GCC C/C++ compiler. Support for interprocessor communication is also included in the mainline Linux kernel via RPMSG

siehe
http://elinux.org/Beagleboard:BeagleBoard-X15

Es gibt aber auch jede Menge Industrieboards mit den TI-Chips, auch von mehreren deutschen Firmen. Habe bei der ersten Suche ein Development Kit bei Phytec gefunden, für 340 Euro
http://www.phytec.de/produkt/system-...phycore-am57x/

Bei den Boards ohne DSP nur mit "Programable Realtime Unit" liegt die Preislatte niedriger. Fängt beim Beaglebone green an, das ist die Variante ohne HDMI, bei Conrad 42 Euro. Der normale Black etwa 60. Aus Deutschland gibt es das hier, bei Conrad für 68 Euro
http://beaglecore.com/

Beispielprojekte aus dem Open Source Bereich, z.B. oben erwähnte 2 Kanal 40 MHz ADC-Anwendung oder auch ein 100 MHz Logikanalysator.

Bare Metal ohne Linux geht auch (TI Starterware).

Mir fehlt etwas die Zeit, mich da weiter einzugraben ...

[Cysign]

Ah, okay. Mit den C66x-DSPs könnte man also evtl. schnell genug sein, um des Problems Herr zu werden?
Ich habe was von 700Mhz gelesen.

Andererseits habe ich gelesen, dass man mir FPGAs an den Ports schnellere Zugriffszeiten erlangen kann als der Kern eigentlich hat.
Auch wurde erwähnt, dass Hardwaretranciever schneller sind als GPIOs.

Ich denke, ich werde mal etwas in beide Richtungen recherchieren.


Angenommen, ich habe nun eine Plattform, die mit 700-1000Mhz Signale detektieren kann, so ist mir noch nicht ganz klar, wann/wie bei einer Funkübertragung dann der Zeitstempel erstellt wird.
Bei langsamen Geschwindigkeiten auf einem Arduino per Knopfdruck kann ich einfach sagen wenn Knopf1 = 0 und dann vom RTC die Zeit auslesen.
Aber ein Funksignal ist kein eindeutiger Trigger wie Knopf1 = 0. Ich empfange also ein Funksignal aber erst an einem gewissen Punkt, z.B. bei der Auswertung der ID des Senders, kann ich dann die Zeit nehmen.
Wenn diese Umwandlung nun auch ungehindert im FPGA oder im DSP erfolgt, wäre dann anzunehmen, dass dies immer annähernd gleich schnell erfolgt?

[Thomas$]

Reflektionen und Störungen gibts auch beim Funk, auch wenn man diese auch nicht hört,... Sichtverbindung ist in jedem Fall von vorteil. Mehrwegeempfäng lässt sich durch Kreuzkorrelation jedoch in den Griff bekommen. Ziel ist es das Spektrum zu spreizen und die Sendeleistung zu reduzieren. --> die Tiere werden weniger gestört ist etwas aufwand aber gute Anwendung für einen FPGA

[Cysign]

Klingt so, als hättest du Erfahreungen mit FPGSs?
Kannst du mir denn ein Board empfehlen, das mir beim Einstieg hilft und evtl. sogar schon schnell genug für diese Anwendung ist?

[i_make_it]

Ich denke, Ultraschall ist in einer nicht genauestens definierten Fläche nicht realisierbar.

Das geht schon, es ist einfach die Reichweite.
Fledermäuse sind mit US bei über 20m praktisch blind.
Und die haben millionen Jahre an ihrem System Entwicklung und Finetuning betrieben.
http://www.schule-bw.de/unterricht/f...choortung.html

Bei Delfinen wurde unter Wasser bei über 100m noch eine Detektionsgenauigkeit von rund 50% getestet.


Bei DZF 77 wird das Signal ja bezogen auf die Entfernung zum DCF Sender synchonisiert.
Das heist du hast keine Synchonisation deiner Komponenten untereinander.
Verändert sich die Positition der Drohne ändert sich auch die Synchonisation die das DCF77 liefert.
Unterschiede bekommst Du dann nur durch Toleranzen bei der Durchlaufverzögerung in der Elektronik.
Zeitsynchonisation geht da nur über die Einstein Synchonisation.
https://de.wikipedia.org/wiki/Einstein-Synchronisation
Wird So ja auch bei den GPS Satelliten gemacht.
Damit ist aber immer noch nicht das Problem der ganggenauen Uhren gelöst.
Vor der Signalverarbeitung befass Dich doch erst mal mit den Zeitquellen die es zu synchonisieren gilt.
Es gibt da nichts auf dem Markt was klein, genau und billig ist.
GPS benötigt für die heute erreichbare Positionsgenauigkeit Cäsium Atomuhren.
Damit Galileo genauer wird, sollen es dort Wasserstoff-Maser Atomuhren werden.

Eine CSAC mit maximaler Genauigkeit liegt bei Rund 1500$ und ist von der Gangenauigkeit schlechter als die Cäsiumuhren beim GPS.
(Eben noch mal nachgelesen Die GPS Uhren haben mindestens 10hoch-13, die CSAC wirbt mit 10hoch-15 Genauigkeit, wäre also besser)
Eine CSAC wie sie in GPS Empfängern zum Einsatz kommt, gibt es hier:
http://www.microsemi.com/products/ti...e-atomic-clock
http://www.microsemi.com/document-po...mic-clock-user
Bei drei Baken liegst Du also bei den Zeitgebern bei rund 4500$ plus Steuern und Zoll.
Dann kommt die Synchonisation und zum Schluss die Auswertung.
Unter 15.000 bis 20.000€ wirst Du am Ende wohl kaum kommen.

http://theconversation.com/why-the-d...loration-53265
Ab etwa Mitte der Seite ist die neue Quecksilber Plasma Atomuhr der aktuell geplanten Generation von GPS Satelliten zu sehen.