Liste der Anhänge anzeigen (Anzahl: 3)
Danke für deine Antwort Besserwessi!
Zitat:
Zitat von
Besserwessi
Die Transducer sind halt Resonatoren im US-Bereich und haben eine relativ begrenzte Bandbreite. Dafür bekommt man mit relativ wenig Leistung eine brauchbare Amplitude und beim Empfänger gleich ein Filterung. Für die Laufzeitmessung ist das tatsächlich nicht ideal, aber so sind nun mal die üblichen Transducer. Das Problem ist halt mitzubekommen welche Periode man gerade empfängt. Die Datentransferrate ist halt durch die Bandbreite begrenzt: die dürfte so in der Größenordnung 1-5 kHz liegen - da sind 1 ms/Bit schon recht gut.
Ja, die Filterung ist echt gut. Ich glaube den Bandpass kann ich mir sogar sparen. Von der Datenrate her bin ich inzwischen bei 0.5 ms/Bit angelangt
Zitat:
Über eine etwas geänderte Signalform könnte man da noch einiges bei der Zeitmessung Verbessern:
Eine Möglichkeit ist dabei als Signal erst etwa 10-20 Periode zu senden (so dass der transducher gut Ampltude erreicht) und dann die Phase um 180 Grad zu ändern - die Ampltude geht dann schnell zurück und auf die andere Phase. Der Empfänger wertet dann den Punkt aus, wo die Amplidude wieder annähernd Null wird. Mit einer Phasenstarren Auswertung (d.h schon etwas Aufwändiger als mit dem HC05 Modul), kann man den Zeitpunkt so recht genau Treffen und damit die Unsicherheit um ganze Perioden überbrücken.
Genau so versuche ich es zu machen
Zitat:
Der Code zum Senden benutzt schon so etwas wie eine Phasenmodulation: bei einem 1 Bit kommt die Extra Verzögerung dazu (sollte vermutlich besser etwa 12 µs sein, nicht nur 5 µs).
Genau, dass es 12µs anstatt 5µs sein müssten (für 180° Phasenverschiebung) habe ich mir auch gedacht. Komischerweise schwingt der Empfänger aber komplett unbeeindruckt weiter. Ich habe vieles durchprobiert und 5µs scheinen am besten zu funktionieren. Warum das so ist weis ich noch nicht so recht..
Zitat:
Das gibt dann beim Empfänger einen deutlichen Einbruch (einmal kurz durch Null) in der Amplitude und auch einen Sprung in der Phase - sofern der Empfänger das misst. Das ist schon ein recht robustes Protokoll. Vermutlich könnte man die Bits sogar noch etwas schneller senden. Bei mehr als etwa 16 Bits muss man sich ggf. noch Gedanken um die Syncronisation machen - wobei der Empfänger im Prinzip die US Periode zählen könnte. Schneller senden hätte den Vorteil, dass einem Echos nicht so dazwischen kommen.
Insgesammt habe ich mir das so vergestellt / entwickelt sich es dahin:
- Es gibt einen Master, Slaves dürfen nur auf Anfrage senden (Analog zu I2C)
- 20 Perioden pro Bit
- Ein Anfangsbit das einfach nur den Empfänger zum schwingen anregt
- 2 Start-bits. Der richtige Abstand der beiden Bits weist darauf hin, dass es ein Paket ist (Und kein anderer Ultraschallsender). Ausserdem dienen die beiden Bits als Refferenzpunkt für die Zeitmessung
- 16 Datenbits
- 2 Parity bits
- für high-bits gibt es eine steigende Flanke (siehe nachfolgenden Inhalt), damit die Snychronisation unterstützt (es zeigt sich nämlich, dass wenn sich Dinge in unmittelbarer Umgebung bewegen es (augenscheinlich) leichte zeitliche Verzerrungen geben kann)
Zum Aktuellen Status. Das ist mein aktueller Versuchsaufbau:
Anhang 29033
Rechts der Sender, der direkt an einen Atmega8 angeschlossen ist. Links der Empfänger.
Anhang 29034
Die symmetrische durscheinende Fläche ist das empfangene Signal (Es sieht so zerhackt aus wegen der chopped-Darstellung). Dieses schwingt um ca. 1.3V und wird durch einen CA3140 als Impedanzwandler gejagt. Anschließend einfach gleichgerichtet und durch C mit R-Last gepuffert, dadurch bleibt nur noch die Amplituden-Kontur der oberen Hälfte bestehen.
Anhang 29035
Von der Amplituden-Kontur wird ein zweites ganz leicht phasenverschobenes Signal erzeugt (R+C), dann werden beide in einen Komparator (CA3140) geführt. Dadurch zeigt der Komparator an ob die Kurve steigt oder fällt (Durch Hysterese werden ganz kleine Schwankungen ignoriert).
Das Ganze funktioniert so gut, dass man bei guten Bedingungen (=obiger Versuchsaufbau) schon allein an der Ausgabe des Komparators die Daten rekonstruieren kann, ganz ohne den Spannungswert der Kontur-Kurve zu beachten.
Liste der Anhänge anzeigen (Anzahl: 3)
Zitat:
Zitat von
Besserwessi
Ein Grund wieso es nur 5 µs für den Sprung sind, könnte sein, dass die Abfrage davor auch noch etwas Rechenzeit braucht. Das könnte noch etwas besser werden, wenn man die letzte Periode vor der Abfrage an die Rechenzeit anpasst und etwas kürzer macht. So hat man halt immer etwas Verzögerung dazu: Man sieht auch bei den folgen von 0 Bits noch ein bisschen Struktur. Eine zusätzliche Verzögerung von 5-7 µs allein durch die IF Abfrage kommt mir aber auch recht lang vor. Man könnte es ggf. am Sendesignal erkennen. Wie schnell läuft denn der µc ?
Weil der interne Oszillator zu ungenau ist um eine Phasnverschiebung um 12µs hinzubekommen (anderer µC -> funzt nicht mehr) habe ich jetzt am Sender einen 12MHz quarz dran. Jetzt sieht das ganze auch schon viel besser aus: Die Wartezeit ist 10µs, die restlichen 2µs gehen vermutlich für das IF usw drauf.
Zitat:
So wie das Signal Aussieht könnte man vermutlich noch bis 0,25 - 0,3 ms je Bit runter gehen - das wäre dann etwa 10-12 Perioden statt 20. Es sollte ausreichen wenn die Amplitude bei einem 0 Bit (als ohne Störung) bis auf etwa 70% des Maximalwertes hoch geht. Länger warten bringt nicht mehr so viel. Nur die Synchrornisation braucht dann ggf. besser ein 101 statt zwei 1 Bits.
Leider musste ich sogar wieder auf 1ms/Bit rauf.. Das liegt daran, dass erst nach so langer Zeit die Amplitude des Empfängers nicht mehr weiter steigt. Ansonsten hat man wenn zwei mal 1 hintereinander gesendet wird eine kleinere Spitzenamplitude als bei 101, was die Zuverlässigkeit der Übertragung deutlich schmälert.
Zitat:
Das Signal sieht so schon sehr gut aus, auch schon einfach nur mit dem Komparator. Im realen Fall muss man aber vermutlich das ganze noch an eine variabel Amplitude anpassen. Mit dem Direkten Signal, also ohne Reflexion wird das Signal ggf. sogar noch Stärker ! So ganz schnell ist das Amplituden-Signal auch nicht mehr - das könnte der µC ggf. auch per ADC auswerten. Für die Daten reicht es ja die Amplituden zu den passenden Zeiten Auszuwerten - die Komparatorschaltung wäre mehr etwas zur Synchronisation und für die Abstandsmessung.
Also ich mache es im Moment mit zwei Komparatoren: Der eine Zeigt an ob das Signal steigt oder fällt (also die Flanken) und der andere ob das Signal über Spitze/2 ist oder nicht (also den Pegel). Wenn eine high-Flanke anfängt und der Pegel (noch) low ist (Nulldurchgang = 1) wird es als eine 1 gewertet. Falls keine Flanken kommen oder der Pegel high ist wird als 0 gewertet.
Hier der Sender.
Anhang 29039
Atmega8 mit besagtem 12MHz Quarz. Die Leitung ist die Versorgungsspannung (4.3V, was vom USB noch so übrig bleibt :))
Der Empfänger:
Anhang 29040
Poti links ist für die Spannung um die das Empfängssignal schwingt. Der IC links ist ein CA3140 als Verstärker, das ist der einzige OP den ich da habe der schnell genug ist. Dummerweise kann der bei 5V single supply nur ca. 2.5V maximal ausgeben -> hier muss noch was anderes her. Das Zweite Poti ist die Last für den C, der die Spannung für die Kontur-Kurve puffert. Rechter IC sind 4x OPs, zwei davon als Komparator (Flanken + Pegel)
Und so sieht das am Oszi aus:
Anhang 29041
Und es funktioniert erstaunlich gut! Über eine Strecke von 6m kann ich das Byte schon stabil übertragen! :cool:
Nur bei Störungen hat man eine Chance von 25% dass die Checksumme stimmt (2bit), von daher können da manchmal Fehler passieren.. (-> längere Checksumme)
Und dabei gibt es noch Verbesserungspotenzial:
- CA3140-Alternative mit rail-to-rail
- MAX232 für Sender
