Ortung innerhalb 100m per Funk möglich?

[Cysign]

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

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

[i_make_it]

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/

[Cysign]

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.

[i_make_it]

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.

[Cysign]

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?

[i_make_it]

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.

[Mxt]

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

[i_make_it]

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/

[Cysign]

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.

[Mxt]

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.