Ortung innerhalb 100m per Funk möglich?

Hallo,

ich wüsste gerne, ob es möglich ist, z.B. ein RC-Auto oder eine Drohne extern zu orten. Also die das RC-Modell bewegt sich irgendwo und z.B. durch das Anpeilen von zwei fixen Sende-Empfangsstationen kann man eine Entfernung zur jeweiligen Station auslesen und damit umschreibende Radien um die Stationen ziehen und somit zwei mögliche Aufenthaltspunkte ermitteln, wo sich die radien schneiden.

Bisher kenn ich nur die Möglichkeit, dem Modell selbst z.B. einen GPS-Sender zu verpassen.
Bei einem Auto ist es halt auch so, dass nicht immer eine Sichtverbindung besteht durch Unebenheiten im Boden (z.B. Offroad).

Mir fällt dazu spontan der Begriff "IBeacon" ein:
https://de.wikipedia.org/wiki/IBeacon
http://www.techtag.de/it-und-hightec...ibeacons-wird/

n iBeacon kann meine ich nicht die Entfernung ermitteln. Entweder du empfängst das Signal oder eben nicht. Eignet sich im Supermarkt für ein Schnäppchenangebot in der Süßwarenabteilung. Aber eine genaue Ortung stell ich mir damit schwierig vor. Zumal der Bereich eines RC-Modells bestimmt 50-100m beträgt. Da müsste man den Boden damit pflastern ;)

Aber ich werd mich da nochmal schlau machen, danke für die Idee!

- - - Aktualisiert - - -

Wäre es prinzipiell nicht schneller und einfacher mit einer analogen Funktechnik?
Wenn das Objekt sich schnell bewegt, aber bei jeder iBeacon-Anfrage eine Authentifizierung mit dem Beacon nötig ist, entsteht ja ein enormer Overhead.

Einfach geht das jedenfalls nicht!
Andere Leute haben sich schon die Mühe gemacht und haben z.B: die Signalstärken mehrerer WLAN-Sendestationen ausgewertet und unter Verwendung derer bekannter Positionen dann eine Position zu berechnen.
Laufzeitermittlungen fallen schonmal komplett flach, dafür mangelt es dir mit Sicherheit am Zugang zur notwendigen Technik.

Das mit der Sichtverbindung und GPS hab ich nicht verstanden, was eminst du damit? Verbindug zum Satteliten?

Ich habe mal ein Projekt in der HS gemacht bei dem ich versucht habe die Ortsbestimmung eines Robos auf ebener Fläche mittels weniger verfügbarer Sensoren möglichst exakt durchzuführen.

Poor-Man-D-Gps war zwar eine Lösung im freien und war auch erstaunlich präzise (1-2m genau), aber ich brauchte schon etwas unterhalb eines Meters

Du könntest aber auf dem Auto einen Sender installieren und den Sender dann anpeilen! (Schmale Empfangskeule mittels passender Antenne)

Eine Entfernungsmessung per Funk ist nur über Laufzeitmessung möglich (siehe GPS, wo eine Zeit einer bestimmten Kugelschale um den Sender entspricht). Die Signalamplitude kann durch zu viele Faktoren beeinträchitgt werden, so das keine verlässlichen Wert ergibt.
Selbst der menschliche Körper kann schon das Feld verändern.

Die Funkmesswagen nutzen z.B. Richtantennen und ermitteln über Höhen und Seitenrichtwinkel von mindestens zwei bekannten Standorten die Position eines Senders.

Zitat:

---

Zitat von Ceos

Das mit der Sichtverbindung und GPS hab ich nicht verstanden, was eminst du damit? Verbindug zum Satteliten?

---

Ich meine, wenn ein RC-Auto offroad fährt, hat es nicht immer Sichtverbindung zu einem möglichen Empfänger.

Allein beim Smartphone merkt man ja schon, wie schnell mal das GPS-Signal verloren geht. Von daher denke ich nicht, dass man hier bei vielen Vibrationen und Schlaglöchern etc. auch nur annähernd eine Position ermitteln kann.

Den Ansatz mit einem Sender am Auto fände ich aber interessant.
Hast du zufällig einen Suchbegriff dafür?

Wenn ich nun zwei Empfänger mit bekannter Position (z.b. 50m zwischen den Empfängern) und synchronisierter Zeitbasis aufstelle und ein Signal vom Auto abschicke, müsste ich doch die Position ermitteln können.
Aber welche Funktechnik eignet sich dazu? Und wie schnell müsste die Auswertung detektiert und berechnet werden, damit ich die Entfernung berechnen kann?

Ich meine mich zu erinnern, dass ich mal mit einem Techniker über frei nutzbare Frequenzen gesprochen habe und da irgendwas im Bereich 433Mhz erwähnt wurde.
Mein E-Gitarrensender funkt etwa im Bereich 863Mhz.
Gibt es da vielleicht zugelassene Sender in diesen Bereichen für genau diese Zwecke?

433MHz (433,05–434,79 MHz)und 863MHz (863-865) sind ISM Bänder (Industrial, Scientific and Medical)
https://de.wikipedia.org/wiki/ISM-Band
Und zwar für SRD (Short Range Device)
https://de.wikipedia.org/wiki/Short_Range_Devices

Im Frequenzplan ab Seite 271 (Eintrag 247001) sieht man was sich auf dem 433MHz Band so tummelt.
Und ab Seite 315 (Eintrag 251001) für 863MHz.
http://www.bundesnetzagentur.de/DE/S...plan-node.html
Da sieht man auch das Du nur mit 10mW unterwegs sein darfst, wärend die Primärnutzer auch mit 5W (433MHz) senden dürfen.
Das kommt daher, das ein ISM DSR Nutzer die primären und sekundären Nutzer des Bandes nicht stören darf und Störungen durch diese hinnehmen muß.
863MHz ist da schon etwas besser was die Störungen angeht, Da kein LTE mehr da ist (Duplexlücke). Vorgesehen war mal das der Bereich auch für mobile Datennetze (LTE) genutzt wird.
Dafür sind jetzt drahtlose Mikrophone (Theater) dazugekommen. Seit 01.01.2016 ist deren bisheriger Bereich LTE zugeschlagen worden.
https://www.thomann.de/de/onlineexpe...teilungen.html

Je nach dem wo man sich befindet, muß man also mit entsprechenden Störungen rechnen.
Aber vom Prinzip ist ISM Funk da der richtige Ansatz.

Bei Pollin gibts fertige 433Mhz-Module. Kann ich mir die einfach kaufen und damit rumspielen oder könnte ich da Probleme (wegen Sendeleistung / Sendedauer) bekommen?
Oder hast du zufällig ne Ahnung, ob ich sowas auch für 863Mhz finden kann?

Wenn ich mir das Datenblatt von http://www.pollin.de/shop/dt/MTU5OTg...endemodul.html anschaue, kann ich keine explizite Sendeleistung finden. Oder ergibt sich diese aus den DC characteristics= 0,002A * 4V = 0,008W - wäre das dann die Sendeleistung? Oder muss hier auch die Dämpfung in dB beachtet werden?

Und wie kann ich berechnen, wie schnell das Signal ist?
Wenn das Signal schneller ist, als ich mit dem Empfänger den Empfang registrieren kann, wäre ja die Auswertung unmöglich.

Im Datemblatt steht 8dBm im 433MHz band und 5dBm im 868MHz Band.
http://www.rapidtables.com/convert/power/dBm_to_mW.htm
Das sind dann 6,31mW und 3,16mW.

Von den 433MHz Modulen habe ich auch mehrere für Telemtrie. Man muß sich halt ggf. ein SCMA/CD ähnliches Protokoll basteln damit Daten auch sicher immer durch kommen.
Das wurde ja für Ethernet aus dem ALOHA Protokoll für ein Funknetz entwickelt.
Ist also genau dafür gemacht.

Die XBee-Pro gibt es in 868MHz.
Oder das Lora Shield für Arduino.

Hallo !

Zitat:

---

Zitat von Cysign

Und wie kann ich berechnen, wie schnell das Signal ist?

---

Das ist aus der Physik längst bekannt. Radiowellen werbreiten sich im Vakuum mit ca. 300 000 km/s. ;)

Danke, die Info hatte ich grade nicht parrat. Irgendwie sind nur die 330m/s vom Schall hängen geblieben - zu der Zeit hätte ich aber auch nicht den Unterschied zwischen Kondensator und Widerstand gewusst :D

300 000 000m ^= 1s
300 000 ^= 1ms
300m ^= 1µs
0,3m ^= 1ns

Mit einem Arduino soll wohl ca. 63ns die kleinst mögliche Zeiteinheit sein. Das entspricht dann etwa 18,9m.
Da muss ich dann wohl auf einen schnelleren Mikrokontroller zurückgreifen.
Wären PIC oder FPGA für die Aufgabe eher geeignet? Leider habe ich mit beiden Plattformen bisher keine Erfahrung - aber das lässt sich ja ändern ;) Muss nur erstmal rausfinden, ob der Chip schnell genug ist, um halbwegs genau zu messen...

//Edit: Ich könnte mir auch vorstellen, ein ESP2866 als µC zu nutzen - das hätte den Vorteil, dass ich die empfangenen Daten auch gleich per WiFi weitersenden kann ;)

Der ESP8266 kann mit 160Mhz angetrieben werden - damit müsste theoretisch als grobe Überlegung ca 2m Genauigkeit erreicht werden.

16Mhz Arduino ~62,5ns => 18,75m
160Mhz ESP8266 ~6,25ns => 1,87m (vermutlich kommt aber noch irgend ein Overhead dazu...)

Das geht doch schonmal in die richtige Richtung ;)

Das ganze ist noch etwas komplizierter.

https://de.wikipedia.org/wiki/Einstein-Synchronisation

Bei Laufzeitmessungen mit Radiosignalen, kann man noch die Zeit die man zur Verfügung hat verlängern, indem man auf FMCW geht und die aufmodulierte Frequenz deutlich langsamer geändert wird wie die die eigentliche Signallaufzeit.
Bei Radar werden FMCW und Dopplereffekt genutzt um Position und Relativbewegung in alle Richtungen erfassen zu können.
Meist ist dort die gesammte Signslverarbeitung aber Analog und erst die reinen Nutzdaten werden rechnergestützt aufbereitet.
Da ist dann mit ein paar Funkmodulen für die Kommunikation nicht viel zu wollen.

http://hforsten.com/homemade-synthet...ure-radar.html
http://hackaday.com/2014/03/17/radar...perture-radar/
http://hackaday.com/2012/12/18/build...pencourseware/

Beim Radar gehe ich aber davon aus, dass ich keinen Fixpunkt als die eigene Position habe.
Bei meinem Versuchsaufbau hätte ich aber zwei (oder falls nötig auch mehr) fixe, bekannte Punkte und einen aktiven Sender. Das dürfte es doch um einiges leichter machen (ohne jetzt deine Links gelesen zu haben - die werde ich mir nacher zu Gemüte ziehen).

Wenn mein Modell ein Signal sendet, logge ich einfach den zeitlichen Eingang des ersten Bits. Dann werte ich den Datensatz aus (z.B. ID) und kann so verifizieren, dass es sich dabei um mein Signal handelt.

Und bei dem zeitlichen Eingang den Du loggen möchtest (und der maßgeblich ist für die Genauigkeit) bist Du bei der Einstein Synchonisation agelangt.
Dein Synchonisationssignal hat die selbe Ausbreitungsgeschwindigkeit wie das zu messende Signal.
Und beide Geschwindigkeiten sind relativistisch.
Willkommen an dem Punkt wo ich vor knapp 22 Jahren auf Radar gewechselt bin.

Es gibt ein paar Arbeiten darüber wie bei den GPS Sateliten Die Uhren abgeglichen werden.
Genau den Aufwand wirst Du auch betreiben müssen, sonst misst Du nur die Laufzeitverzögerung der Elektronik in den Sendern und Empfängern.
Die muß übrigens mit sehr hoher Präzission und extrem geringer Tolleranz immer gleich sein, da diese bei den kurzen Strecken ein Vielfaches der eigentlichen Laufzeit auf der Strecke ausmachen und Schwankungen so Fehler im Bereich mehrere 100% Verursachen.
Bei dem Projekt solltest Du Dir zuerst Gedanken um alle möglichen Fehlerquellen machen und dann jede Idee dagegen abklopfen.
Sonst Investierst Du viel Zeit, nur um hinterher Festzustellen das die Physik "Nein" sagt.

Um die Abweichungen gering zu halten, würde ich gerne einen wesentlich schnelleren Mikrokontroller nutzen.
Ich hab zwar Infos zu ein paar 400Mhz Atmel-ARM finden können, aber bisher noch kein geeignetes Eval-Board.

Wichtig ist, dass die verwendeten Kontroller auf Empfangsseite in möglichst kleinen Zeitintervallen rechnen können und diese ständig synchronisiert werden.

Danach ist auch die Lage der Empfangsantenne wichtig. Da nicht sichergestellt ist, dass das Modell immer in waagerechter Position sendet, könnten evtl. mehrere Antennen auf Empfangsseite mit verschiedener Ausrichtung Sinn machen?

Das wären spontan die einzigen Fahlerquellen, die mir in den Sinn kommen.
Ich habe bisher aber auch noch keine Erfahrungen in diesem Bereich.

Auf welcher Basis würdest du Überlegungen anstellen um so ein Projekt anzugehen?

Mehrere Antennen die bezogen auf die Kugelwelle des Signals nicht auf dem selben Radius (Kugelschale) zum Sender liegen, bedeuten daß das selbe Signal zeitversetzt mehrfach empfangen wird und als verzerrtes Summensignal zum Empfangsverstärker geleitet werden.
Ohne entsprechende Signalaufbereitung, kann daß das Funkequivalent eines prellenden Schalters geben. (abhängig vom Antennenabstand und dem zeilichen Verlauf des Signals).

Gezielt setzt man mehrere Antennen bei Phased Array Antennen ein.
Da kann man über die Verzögerung dann die Richtung aus der das Signal kommt bestimmen.
Allerdings hat da jede Antenne ihren eigenen Verstärker und Empfänger.

300.000.000 m/s - 1Hz
300.000 m/ms - 1kHz
300 m/µs - 1MHz

30 m/µs - 10MHz
3m/µs - 100MHz
1,5m/µs - 200MHz
0,75m/µs - 400MHz

0,3 m/ns - 1GHz

Wenn also bei Deiner CPU ein Takt vergeht, breitet sich das Signal 0,75m aus.
Wenn Du es schafst auf 2 Takte genau jedes einkommende Signal zu Erfassen und deine Uhr Dabei auch noch absolut synchon ist zur Uhr des Senders, dann kommst Du bei 100 Metern auf eine Genauigkeit von 1,5%.
Das mit der Uhr wirst Du nicht schaffen, wenn ich mir Größe, Gewicht und Preis der Uhren in den GPS Sateliten ansehe.
Aus eigener Erfahrung sage ich das Du mindestens einen schnellen DSP dafür brauchst.
Mit einem normalen µC ist da kein Blumentopf zu gewinnen (Das Uhr Problem ist dann aber immer noch ungelöst).
Genau die selben Überlegungen führten mich 1994 Zu PIC µCs, wiel die damals als RISC Prozessoren mit 20MHz das schnellste waren was es (erschwinglich) gab.
Danch bin ich dazu übergegangen möglichst viel analog zu machen.
Bei einem Ringmischer erhält man z.B. als Produkt zweier empfangener Frequenzen eine Analogspannung deren Wert man mit einem ADC dann einfach ermitteln kann.
Das kann man z.B. bei Mehreren planar angeordneten Antenne nutzen um die X und Y Winkel eines Senders relativ zum Empfänger zu ermitteln.
Mit mehreren solcher Phased Array Antennen mit Bekannten Positionen zueinander kann man dann die Sender Position triangulieren.
Das setzt natürlich eine Mindestgröße der Drohne vorraus, damit man die Systeme möglichst Weit auseinander bekommt.
Da das alles ja auch was wiegt, dürfte sich der Abstand aber alleine daraus ergeben, das man die Drohne entsprechend groß bauen muß um den notwendigen Auftrieb zu erhalten.
Bei einem klassischen Flugzeug wären Flügelspitzen, Bug und Heck prädestinierte Positionen um entsprechend Abstand zu bekommen.
Oder Verkleinerung der Antennen in dem man auf höhere Frequenzen wechselt.
Das Bringt dann bei gleicher Abmessung des Trägersystems einen größeren Abstand zwichen den Mittelpunkten der einzelnen Antennenarrays. Aber leider halt nicht besonders viel.

Interessant, was Ihr so alles macht.

Vielleicht ein ganz kleiner Beitrag in Sachen schneller Controller: Es gab da kürzlich dieses Google Projekt
https://research.googleblog.com/2016...board-for.html

Die haben einen TI Prozessor verwendet, weil es da spezielle Kerne gibt (PRU), wo jeder Befehl die gleiche Zeit braucht. Das ist bei normalen Cortex-M ja nicht der Fall.

Und die schnellsten Atmel Chips sind ja Cortex-A. Kann man die, was die IO-Performance angeht, einfach mit den kleineren vergleichen ? Cortex-A ist ja eher was wo man Multitasking macht, ob nun mit oder ohne Betriebssystem.

TI hat da diverse Teile, auch Cortex-A, Cortex-M und DSP kombiniert. Es gibt da auch Boards für
http://www.ti.com/lsds/ti/processors.../overview.page
http://www.ti.com/lsds/ti/processors.../overview.page
http://www.ti.com/lsds/ti/processors.../overview.page

Ich denke das Thema mit der Uhrensynchonisation bricht dem Verfahren den Hals.
Wenn zwei Uhren einen Gleichlauffehler von einer Nannosekunde entwickeln, sind das 30cm Fehlmessung.

Die Laufzeitmessung Funktioniert normalerweise damit, das der "Reflektor" eine immer gleiche Laufzeitverzögerung hat und auf das Empfangene Paket antwortet.
Bei dem Verfahren baucht jeder "aktive" Part eine genaue Uhr, aber es ist keine Synchonisation zwichen verschiedenen Uhren notwendig.
Der "aktive" Part misst die Laufzeit vom Senden des Telegramms bis zum Empfang des "Echos".
Zieht davon die Durchlaufverzögerung des "Reflektors" ab und teilt durch zwei.
Das Ergebniss kann er dann dem Reflektor mit dem nächsten Telegramm mitteilen. Somit wird immer gemessen und das letzte Ergebniss übertragen.
Mit drei "aktiven" Baken an festen Positionen bekommt der "Reflektor" dann drei Abstände zu den Referenzpositionen der Baken mitgeteilt.
Der andere Weg der Positionsbestimmung ist halt durch Triangulation drei Sätze von Höhen und Seitenwinkeln zu erhalten und über die Referenzpositionen damit den Standort zu ermitteln.
Die Entfernung ist dann halt als Ergebniss von trigonometrichen Berechnungen verfügbar.


Ergänzung

Hier ein Link zu einem einfachen DLR Artikel zu den Atomuhren in GPS Satelliten.
http://www.dlr.de/next/desktopdefaul...85_read-24092/

Ich bin gestern drauf gestoßen, dass meine Idee mit 2 Empfangspunkten Mumpiz ist. Damit kann ich immer nur eine Senkrechte zur direkten Luftlinie zwischen den beiden Empfangspunkten errechnen, auf der sich mein Sender bewegen kann. Ich brauche also mindestens 3 Empfänger mir fixer Position.

Hinsichtlich einer Prozessorbasis bin ich leider auch noch nicht fündig geworden, was da schnell genug sein könnte.

Was das mit dem Ringmischer/-modulator anbelangt (den Begriff kannte ich bisher nur von Modelling-Gitarrenverstärkern und Synthesizern, steig aber jetzt erst langsam dahinter, was der macht) halte ich eher für unmöglich. Bei einer Neigung kann es ja schon sein, dass das Signal nicht mehr optimal so ausgestrahlt wird, dass es in einer nutzbaren Qualität beim Empfänger ankommt.

Theoretisch müsste doch ein Raspberri mit Realtime-OS schnell genug sein, um die Auswertung im Bereich von 1000Mhz hinzubekommen.
Ich könnte die Uhrzeit synchronisieren, dann die Daten empfangen und anschließend nochmal die Uhrzeit synchronisieren, dann auf dem Zielrechner den Synchronisationsfehler herausrechnen (damit die Raspberrys so wenig wie möglich belastet werden) und dann anhand der 3 Latenzen ausrechnen, wie weit der Sender von den 3 Messpunkten linear betrachtet entfernt ist. Darauß bilde ich einen virtuellen Radius um die 3 Punkte, projeziere das Ganze auf meine bekannten Abstandswerte und....naja, bevor ich Luftsprünge mache, muss ich jetzt erstmal ne Idee entwickeln, wie ich sowas umsetzen kann.
Ich hab nur n Oszi mit 60Mhz hier, da muss ich zum Messen der Geschwindigkeit mit nem Realtime-OS mein Signal erstmal künstlich verlängern.

Also ein Flaschenhals bei der Prozessorplatform ist ja die Anbindung der IO-Systems. Der Chip im Raspi ist ja Multimedia-IC von Beruf. Da sind die ARM-Kerne ja über einen Bus mit der IO-Einheit verbunden. Habe erst kürzlich irgendwo gelesen, wenn man schnelles SPI macht, begrenze das die Geschwindigkeit der digitalen IOs.

Zitat:

---

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

Zitat:

---

Zitat von oberallgeier

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.:confused:

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

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.

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 ;)

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

Zitat:

---

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

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?

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

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?

Zitat:

---

Zitat von Cysign

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.

Zitat:

---

Zitat von 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.

---

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