Liste der Anhänge anzeigen (Anzahl: 1)
Suche einfache Ultraschall Empfänger + Sender (halbe HC-SR04)
Hallo,
ihr kennt ja mit Sicherheit die HC-SR04 Module:
Anhang 29026
Das sind Ultraschall Distanzsensoren, die einen high-Pegel für die Laufzeit des Tons (Sender -> Gegenstand -> Empfänger) ausgeben.
Was ich jetzt suche sind im Prinzip halbe HC-SR04:
- Sender Modul: Sendet einen Ultraschallton solange an einem Pin high anliegt
- Empfänger Modul: Pin high solange dieser Ultraschallton empfangen wird
Das ganze sollte 5V kompatibel sein und sich in seiner Komplexität auf die aufgeführten Punkte beschränken (Hintergrund ist, dass ich mich mit der Erzeugung des Tons als auch der Filterung des empfangenen Tons nicht befassen möchte). Sender und Empfänger dürfen auch ein einziges Modul sein, aber ich muss beides unabhängig ansteuern/auslesen können (Ich möchte via Ultraschall u.a. einige Bytes schicken)
Ich dachte sowas schon mal irgendwo gesehen zu haben, kann jetzt aber nichts derartiges finden...
Würde mich über den ein oder anderen Tipp freuen
Simon
Liste der Anhänge anzeigen (Anzahl: 1)
Also einfache Abstandsmessung klappt mehr oder weniger:
Anhang 29027
Allerdings gibt es einige Probleme, vor allem hinsichtlich der Datenübertragung:
- Die Empfängerkapsel hat anscheinend relativ viel Masse, d.h. wenn der Ton kommt braucht sie Zeit um anzuschwingen (ich vermute ein Grund warum der µC zu viel Abstand anzeigt) und wenn der Ton endet schwingt sie sehr lange nach
- Alles muss extrem schnell und auf die 2-3 µSekunden genau gehen. Ich glaube ich muss mich doch in Assembler einarbeiten.. (Einfach PWM mit Timer geht für Datenübertragung schlecht, weil man schlecht die Schwingungen zählen kann. Auch sollten nacheinander folgende highs des Datenstroms die gleiche Phasenlage haben, damit der Empfänger einfach weiterschwingen kann (sonst geht die Amplitude erst durch 0) und das ist schwierig wenn sich schon einzelne C-Befehle (z.B. Jump+for-Abfrage) als Phasenverschiebung bemerkbar machen (und man weis nicht wie lange die Befehle genau dauern))
- Der angebliche max232a (http://uglyduck.ath.cx/HC-SR04E/HC-SR04.svgz) ist bei mir keiner (hat auch keine Beschriftung..). Weder ladungspumpt noch invertiert er das Signal. Ich habe nachgemessen -> die Ein- und Ausgänge sind einfach kurzgeschlossen :mad::mad::mad:
Ich glaube ich mache gleich ein eigenes Design... (BTW hier gibts ein sehr gutes Datenblatt zu solchen Kapseln: http://www.reichelt.de/Sensoren/MUS-...SET=16&WKID=0& Daran werd ich mich wohl orientieren )
Liste der Anhänge anzeigen (Anzahl: 2)
Zitat:
Zitat von
Peter(TOO)
Was spricht gegen eine Amplitudenmodulation des Sendesignals?
Am Anfang dachte ich, dass es einfach zu lange dauert bis Amplitude der schwingenden Empfängerkapsel wieder runtergeht. Aber eine Messung zeigt, dass es mit ~ 1Bit/ms gehen könnte:
Anhang 29030
Man kann den Nachteil dieser Emfpänger für Abstandsmessungen sehen: Man kann nicht genau sagen wann der Ton beim Empfänger angekommen ist, da die Amplitude nur langsam ansteigt. Das macht die Abstandsmessung ungenauer (die Abweichung von ~1cm im letzten Bild hängt glaube ich damit zusammen. Warscheinlich wird im orignalen Controller des Moduls ein Pauschalwert abgezogen, der der Zeit enstpricht die der Sinus am Emfpänger braucht um als Signal (also kein Noise) erkannt zu werden)
Vielen Dank für die Beschreibung zur Umsetzung einer Amplitudenmodulation! (In die Richtung geht auch mein Ansatz unten)
Zitat:
Zitat von
PICture
Dann müsste man, wie im Datenblatt (DB):
http://www.micropik.com/PDF/HCSR04.pdf mit Pegelwechsel beim Empfänger immer bis zum "Anschwingen" und "Ausklingen" abwarten bzw. schnelle Datenübertragung mit anderen Wandler ohne schwingender Masse z.B. LED + Fotosensor versuchen.
Also Akustische Datenübertragung möchte ich nutzen, weil ich gleichzeitig die Laufzeit zur Berechung des Abstands brauche. Zwar währe ein zweiter Kanal zur Datenübertragung denkbar (allerdings dann gleich Funk, weil nicht immer gegeben ist dass der Lichtstrahl nicht unterbrochen wird (wird für draussen)), aber beides in einem wäre mir natürlich lieber.
Zitat:
Es könnte auch sein, dass die Chinesen zuerst die Bezeichnung entfernt haben und danach verkehrten IC eingelötet haben bzw. als Schutzmasnahme gegen Kopieren ein paar Brücken in Kunststoff als IC versteckt haben.
Ich vermute, dass irgend ein Chinesischer Hersteller das Modul nachgebaut hat und für billig billig den falschen MAX232 aufgesessen ist. Beim Test hats trotzdem funktioniert also wirds schon passen. So besonders ist das Modul ja auch nicht, dass man das reverse-Engineering großartig unterbinden müsste. Wenn dem Hersteller die 5V genügen hätte er sich den MAX232, 1 Transistor, 1 Widerstand und 5 Kondensatoren sparen können.. (der µC hat im übrigen auch keine Beschriftung, aber der tut was er soll)
Zitat:
Als x-Entwickler kenne ich sowas schon lange, dass früher z.B. defekte Dioden als Brücken benutzt wurden um Reparaturen ohne Schaltplan praktisch unmöglich zu machen, weil auswechseln solcher Diode mit guter, das ganze nur noch veschlimmert hat. :confused:
Also das ist ja wirklich dreist :-) Heute findet man dafür überall proprietäre Software+LockBits und ASICs..
Inzwischen habe ich viel herumprobiert, und bin heute Vormittag auch ein gutes Stück weitergekommen:
Anhang 29031
Das Prinzip ist recht simpel: 1Bit=20Wellen 40KHz. Um bei Bit=high den Nulldurchgang der Amplitude zu erzeugen wird zwischen zwei Bits eine Pause von 5µs (+ein wenig CPU-Zeit) gemacht. Das hat zur folge, dass die Empfängerkapsel aus dem tritt kommt und neu einschwingen muss. Der Code ist auch pipieinfach:
Code:
void Tx (uint8_t data)
{
uint8_t stream[2+8+1];
uint8_t i, j;
stream[0]=1;
stream[1]=1;
for(i=0; i<8; i++)
{
stream[2+i] = (data&(1<<i))?1:0;
}
stream[10]=1;
for(i=0; i<2+8+1; i++)
{
for(j=0; j<20; j++)
{
Clear(Tx_PORT, Tx1);
Set(Tx_PORT, Tx2);
_delay_us(12);
Set(Tx_PORT, Tx1);
Clear(Tx_PORT, Tx2);
_delay_us(12);
}
if(stream[i])
_delay_us(5);
}
}
[...]
Tx(0b11000110);
Ich glaube das könnte was werden...
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
