Ortung innerhalb 100m per Funk möglich?

[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?

[Mxt]

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.

Wie gesagt, eigene Erfahrungen habe ich da nicht. Nur vor vielen Jahren mal mit TMS320 Einsteckkarten für den PC gespielt. Das ist quasi der Großvater.

Die Katalogseiten hatte ich ja oben schon verlinkt. C66 gibt es bis zu 8 Stück mit 1,4 GHz im IC (plus bis zu 4x ARM), aber wohl nicht als Bastelboard.

Wenn ich mir die zitierten Beispiele zum "kleinen" AM3358 anschaue, sind die zahlreichen Kerne bei so schnellen Anwendungen im Team gefordert. Da ist mehr Fliessbandarbeit gefragt, als ein Superprozessor, der alles macht. Die IO-Kerne schaufeln wirklich nur Bits hin und her, ohne groß über deren Bedeutung nachzudenken. Die PRU-Kerne in den TI Chips haben auch einen Block gemeinsamer Register, d.h. die können wirklich auf CPU-Clock Ebene verzahnt an Daten arbeiten. Ob die DSP nur über Shared Memory oder noch auf anderem Wege kommunizieren können, müsste man im Datenblatt erforschen.

Der oder die ARM Kerne, meist dann unter Linux, kommen dann erst zum Einsatz, wenn die anderen Kerne die Daten im Arbeitsspeicher angerichtet haben.

[Edit]
Was mir gerade noch einfällt, es gibt auch die Kombination ARM plus FPGA z.B. hier
http://www.xilinx.com/products/silic...l#productTable

[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.