Druckbare Version
Hallo zusammen
für meinen kleinen SRF02 suche ich gerade den Hexcode um den anzusteuern. Leider finde ich nur komplette Programme wo die einzelnen Hexzahlen für die Steuerung irgendwo versteckt sind.
Soweit ich das Datenblatt verstehe:
Adresse: 0xE0
Starten: 0x51
Aber wie kann ich die Register ansprechen? Die werden nicht als Hexzahlen angegeben :-(
Hat jemand die Lösung?
Hallo Hanno,
das Leseregister wird einfach mit "2" abgefragt, bei Slave_read das Slave-Id +1 nicht vergessen:
...
waitms 65
I2cstart
I2cwbyte 0xE0 (dec 224)
I2cwbyte 2 (dec)
I2cstop
I2cstart
I2crbyte Slaveid_read
... High Byte abfragen, ACK
....Low Byte abfragen, NAck
I2cstop
Damit liest Du automatisch ab Register 2, danach auch gleich das Register3 mit aus.
Dann wird es hier im Beispiel an die Funktion zum zusammen fügen übergeben, der aus den beiden Byte-Werten einen Integer macht und dann den richtigen Entfernungswert ausgibt.
(Die Beispieldateien in Bascom fürs RN_Control von:
http://www.shop.robotikhardware.de/s...roducts_id=168 )
@Hexplorer funktioniert so leider nicht, denn ich verwende gerade keinen µC sondern meinen i2c adapter. daher brauche ich alles genau in Hexwerten.
Allerdings glaube ich, dass ich im Moment noch daran scheitere den Sensor überhaupt messen zu lassen, denn wenn ich das richtig verstehe müsste die LED bei jeder Messung aufleuchten. Sprich es würde sich ein sehr schneller blinken ergeben, wenn der Sensor misst. Nur leider leuchtet meine LED gerade mal beim Einschalten kurz (Adresscodierung) auf und dann tut sie gar nichts mehr.
Bisher habe ich es mit dem Adapter noch nicht geschafft Sensoren auszulesen, nur schreiben klappt ganz wunderbar.
Ich versteh einfach nicht wie oder was mit diesen "Register" gemeint ist. bzw. an welcher Position ich auslesen muss.
Naja, der Hexwert für dezimal 2 ist ... 0x02 , oder;) Und Slave-Id_read = 0xE1 (dec 225)
Aber dann musst du dein ergebnis noch selbst ausrechnen, weil es ja nur als 2 einzelne bytes reinkommt.
Vermutlich auch hier wieder das Problem das der I²C Adapter nicht selbst die PullUps verbaut hat? Hast Du welche eingefügt?
Der Adapter hat Pull ups verbaut, daran liegt es nicht.
Wenn ich S E0 00 51 P sende dann bekomm ich auch drei mal Ack zurück.
Danach versuche ich S E1 ??? P und bekomme nur scheinbar willkührliche Hexwerte zurück und "Wrong command"
- - - Aktualisiert - - -
Huch warum dass? Ich dachte das Register 0x00 ist für den Befehl zuständig
Muss ich vor jeder Abfrage des Messwerts ein Befehl 51 schicken?
Abgesehen davon will ich ja noch auslesen, aber irgendwie bekomm ich da keine vernünftigen Werte angezeigt .
versuche mal einzeln rasuzuholen: S E1 03 P und dann noch S E1 04 P. Ich kenn mich mit TerminalI²C nicht so aus, ich würde selbst das RN-Control programm vorziehen. Kann sein das du nur ein Register zur Zeit lesen kannst?
Mhm nein eigentlich nicht. Allerdings habe ich jetzt scheinbar eine Lösung gefunden. Zumindest bekomme ich bei S E1 04 P folgende Anzeige:
05 00 1B 00
So ganz versteh ich jetzt die Umrechnung in die Entfernung nicht: denn
Register 0: 05
Register 1: 00
Register 2: 1B
Register 3: 00
Stimmt das so?
Du musst insgesammt 3 pakete senden, einmal um die messung zu starten, dann um das Register das du auslesen willst festzulesen und dann ein read um die daten zu lesen.
also
S ID 0 51h P (kp woher die 0 kommt, steht so im datenblatt)
dann Register festlegen:
S ID 2 P
und dann das lesen:
S ID+1 ack und nack und stop (keine ahnung, wie das bei deinem i2c dingens geht)
Alles von hier Seite 6
http://www.robotikhardware.de/download/srf02doku.pdf
E: Am einfachsten wäre wohl register 1 auszulesen, denn das sollte immer 0x80 zurück senden, wenn das klappt, würde ich weiter versuchen.
Also dann mit S ID 1 P
S ID+1 nack P
Hallo robin,
geht ein wenig einfacher zum Glück. Ich kann S E1 23 p alle Register auslesen und anzeigen. Es kommt dann sowas:
KKK05 00 1D 00 0F 00 00 00 00 00 00 00 32 04 00 BB 06 0B 05 0F 00 00 00 00 00 05 51 32 8B 00 1E 37 FF FF AF
Wobei KKK die Bestätigung für S E0 0 51 p ist danach kommt immer 00 (egal wie weit der Abstand ist) und dann ändert sich 1D je nach Abstand zum Hindernis. Der Rest bleibt gleich zubindest bis 32 04...
ich vermute sehr stark, dass sich der Längenwert in den 1D verbirgt wobei ich aber noch nicht weiß wie die Umrechnung ist? Wir der Wert gleich direkt in cm angegeben und ich muss nur 1D in Dezimal konvertieren?
Würde bisher ganz gut hinkommen bei kleinen Werten zwischen 15 und 30cm
EDIT: Passt auch für große Werte. Ist zwar noch nicht die eleganteste Lösung aber sie funktioniert.
- - - Aktualisiert - - -
Danke noch mal an alle die geholfen haben. Die Erkenntnis habe ich jetzt mal im RN-Wiki festgehalten bei meinem Adapter Threat.
Hallo!
Ich weiß nicht ob sich Dein I²C Adapter ähnlich verhält, aber ich kann bei meinem von ELV mit folgendem String
„SE0 00 51 P L0015 SE0 01 SE1 03 P“ meine SRF08 auslesen.
Da Du nur High/Low als Entfernungsbyte ab Register 2 benötigst und 65ms Pause zwischen Start und auslesen, könnte folgende Eingabe funktionieren:
„SE0 00 51 P L0045 SE0 02 SE1 02 P“ (Ein Versuch wäre es wert)
„SE0 00 51 P“ sendet die Aufforderung zum Messen in Zentimeter.
„L0045“ wäre die Pausenzeit bei Einstellung des Adapters (Auslieferungszustand ELV) und „SE0 02 SE1 02 P“ der Lesebefehl von 2 Byte ab Register 02.
Gruß André
Im Prinzip mach ich es genau so, nur dass ich die Pausezeit nicht drin habe und gleich direkt die Register auslese:
SE0 00 51P SE1 03P
Mit dieser Befehlsfolge liest er allerdings einfach alle Register aus bis Register 3.
Am Sonntag bin ich wieder zuhause, dann kann ich deine Idee mal testen und berichten. Ich wollte den SRF02 eh noch über ein Matlab skrip ansteuern und die Entfernung grafisch darstellen lassen.
Oh...Sorry,
hatte ich gar nicht gesehen, ich hatte nur den langen Antwortstring im vorherigen Post endeckt.
Und ich hatte bei größeren Entfernungen Probleme, da das Register beim SRF08 zu zeitig gelesen wurde, deshalb bei mir die "Wartepause".
Ich wollte dich jetzt auch nicht durcheinander bringen, wenn alles funktioniert ist es ja OK...
Gruß André
Hallo Andre_S
gerade habe ich es nochmal getestet dein Code funktioniert teilweise, mit
SE0 00 51P L0065 SE1 03P kann man sauber messen, denn der Sensor hat dann sicher den letzten Wert im Register.
Viele Grüße
Hanno
EDIT: Die Antwort am Hyperterminal sieht dann etwa so aus: KKK00 01 54, damit ist die Distanz 154xh bzw. 340cm.
Hallo Hanno,
danke für die Rückmeldung!
Die Pausenzeit war bei mir auch wichtig, allerdings hatte ich sie verringert, da ich innerhalb des Raumes nicht die max. Sensorentfernung erreiche und somit das Register rechtzeitig aktuelle Werte hat.
Möglich, dass mein String für den Sensor SRF02 in C# auch mal in etwa so aussah, hatte diese dann mit den SRF08 ersetzt, da die Sensoren deutlich korrektere Ergebnisse in Bezug auf schräge Flächen lieferten, unabhängig der besseren Nahfeldentfernung.
Gruß André
Kann mir jemand helfen bei der Änderung der Adressen?
Ich habe jetzt drei SRF02 auf meinem Sensorkopf und möchte diesen natürlich individuelle Adressen geben. Dazu habe ich mich genau an die Anleitung gehalten und die Sequenz:
S E0 A0 P
S E0 AA P
S E0 A5 P
S E0 E4 P
geschickt.
Ich habe auch nach jedem Befehl ein KK zurück bekommen, aber der Sensor akzeptiert die neue E4 Adresse nicht, sondern meldet sich weiterhin nur bei E0. Nach Power Reset meldet die LED auch wieder Adresse E0.
Muss man noch irgendwas machen oder habe ich etwas übersehen?
Ich hab so ein Teil nicht, kann also nichts testen. In der Anleitung steht:Zitat:
Zitat von HannoHupmann
Wenn ich jetzt die obige Schreibweise richtig verstehe, steht S für Start und P für Stop. Ein I2C Schreib-Telegramm beginnt mit dem Adressbyte, dann folgt die Registeradresse und dann die Daten.Zitat:
Die einzelnen Bytes dieser Sequenz müssen an das Register 0 gesendet werden. Man muss also 4 getrennte I2C Schreibbefehle nutzen, wobei der Abstand zwischen jeder Registerbeschreibung 50ms sein sollte.
Um Beispielsweise die Standard ID E0 auf F2 umzustellen, müsste nacheinander das Register 0 mit den Werten A0, AA, A5, F2 beschrieben warden.
Nach der Beschreibung müßte das so aussehen:
Start
0xE0 // Slave Adresse
0x00 // Register Adresse 0
0xA0 // Code
Stop
usw.
MfG Klebwax
Hallo,
ist lange her und ich habe nur die SRF08 geändert, hoffe dies ist gleich…!
Was ich mir damals aufgeschrieben habe war folgende Sequenz, (z.B. zur Änderung auf E4) welche ich komplett so übertragen habe:
SE0 00 A0 P L0035 SE0 00 AA P L0035 SE0 00 A5 P L0035 SE0 00 E4 P
Gruß André
Vielen Dank, das wars!
Mit den beiden 00 davor hat es geklappt und jetzt hat jeder SRF02 seine eigene Adresse.
EDIT: Gleich mal in unsere Wiki eingetragen, damit zukünftig niemand mehr den gleichen Fehler machen muss.
Könnte es sein, dass ich beim schreiben der falschen Adressen S E0 A0 P; S E0 AA P usw.. den Sensor verbuggen kann?
Aktuell habe ich nämlich das Problem, dass von meinen drei Sensoren nur einer Werte zurück gibt. Die anderen Beiden melden zwar KKK zurück beim schreiben aber im Register steht dann nur 05 00 00 beim lesen. In den letzten vier Ziffern sollte sich der Sensorwert verbergen. Bei Sensor2 tut er das und bei 1 und 3 leider nicht. (Sensor 2 sendet korrekt den Wert zurück)
Jetzt weiß ich, dass ich beim Adresse wechseln Sensor1 sicher die falschen Befehle geschickt habe und möglicherweise auch Sensor3. Beim Sensor2 wusste ich wie es geht.
ideen / Lösungen?
Adressen und Befehls Sequenzen:
Sensor1 = E0 -->S E0 00 51P (Pause = 0,65ms) S E1 03 P --> KKK 05 00 00
Sensor2 = E2 -->S E2 00 51P (Pause = 0,65ms) S E3 03 P --> KKK 05 00 2A
Sensor3 = E4 -->S E4 00 51P (Pause = 0,65ms) S E5 03 P --> KKK 05 00 00
Für meine I²C-Tests mit dem ELVDing hatte ich mir ne "Bibliothek", eine *txt-Datei, mit den wichtigsten Sequenzen geschrieben. Hab ich grad rausgeholt und zwei SRF02 (E0 und E2) angeschlossen. Dann die (angepassten) Sequenzen gesandt:Zitat:
Zitat von HannoHupmann
Testaufbau: E0 zeigt auf Pappdeckel auf knapp 30 cm, E2 zeigt auf Deckenlampe in ca. 145 cm Entfernung
Eingabe:
s e0 w 00 51 p Adressiere dev E0, schreibe auf Adr 00 Byte 51hex
. . . . . . . . . . . . . . .> Ausgabe KKKK, neue Eingabe (dauert >> 60 ms)
s e1 00 p . . . . . . . . . Adressiere dev E3, lesen
. . . . . . . . . . . . . . .> Ausgabe KKKK00 1C 00 14 00 00 <\r><\n>
. . . . . . . . . . . . . . .> also 28 cm
s e2 w 00 51 p Adressiere dev E2, schreibe auf Adr 00 Byte 51hex
. . . . . . . . . . . . . . .> Ausgabe KKKK, neue Eingabe (dauert >> 60 ms)
s e3 00 p . . . . . . . . . Adressiere dev E3, lesen
. . . . . . . . . . . . . . .> Ausgabe KKKK00 92 00 0A 00 00 <\r><\n>
. . . . . . . . . . . . . . .> also 146 cm
oberallgeier, genauso bzw. ähnlich mach ich es auch. Nur bekomm ich als Rückmeldung nur KKKK 05 00 00 und das egal wie weit oder nah sich ein Gegenstand vor dem Sensor1 oder Sensor3 befindet.
Bei Sensor2 funktioniert es genau so, wie oben von dir beschrieben.
Hallo,
"verbuggen" kann ich mir irgendwie nicht vorstellen, selbst undokumentierte Codes sollten nicht zu so was führen, besonders da 0x00 ja das Befehlsregister ist und du 0x00 ja nicht gesendet hattest....
Bist Du sicher das die Adressen E0 und E4 auch stimmen, achso dass müsstest Du ja an der LED sehen, gibts beim SRF02 sicher auch...
Hast Du eventuell ein Programm in dem ELV Adapter hinterlegt...?
Kannst Du das ganze auch mal über die serielle Kommunikation statt I²C laufen lassen?
Gruß André
@Andre_S also ich kann dem "defekten" SRF02 eine neue Adresse zuweise und sie darunter ansprechen. Wenn ich ihnen Befehle über den i2c adapter schicke, dann bekomme ich auch ein K zurück. Sie verhalten sich genauso wie der funktionierende SRF02. Einzig, dass sie bei S E0 00 51 P als Befehl zwar KKK schicken aber dann beim Auslesen mit S E1 03 P nur 05 00 00 zurück geben. Bei meinem funktionierenden bekommen ich, bei dieser Befehlsfolge genau den Sensorwert zurück geliefert.
Die beiden defekten schicken mir gar nichts außer 00 00. Die LED blinkt auch und es scheint alles zu funktionieren. Zumal ich ja einen SRF02 habe der mit den gleichen Befehlssequenzen korrekt arbeitet.
Seriell kann ich mal noch ausprobieren, aber ich habe wenig Hoffnung.
Das finde ich verblüffend und verdächtig. MÖGLICHERweise liegts an der Softwareversion ? aber das mit einem gaaanz großen Fragezeichen. Andererseits:Zitat:
Zitat von HannoHupmann
Zitat:
Zitat von oberallgeier
Zitat:
Zitat von HannoHupmann
Eine alte WEisheit der Programmierer lautet "... genauso ..." und "... bzw. ähnlich ..." können ganz verschiedene Paar Schuhe sein. Sorry, aber vielleicht versuchste mal genau meinen genannten Code (klar - die Adresse müsste angepasst werden) ? (Anm.: wenn ich mich richtig erinnere, stimmt mein Code nicht immer genau mit der Dokumentation des ELVtruc überein!)Zitat:
Zitat von HannoHupmann
@Oberallgeier, Also deinen Code habe ich genauso (wirklich 1:1) bei meinem funktionierenden SRF02 angewendet und dort geht es. Er ist demnach definitiv korrekt.
Bei meinem nicht funktionsfähigen SRF02 tut sich leider nichts. Sie melden statt dem Entfernungswert nur 00 00 00 09 zurück und keinen Sensorwert. Ich habe es sogar versucht mit der gleichen Adresse E2, aber auch hier gleiches Ergebnis.
Die Adresse kann ich offensichtlich ändern, langsam vermute ich wirklich, dass die SRF02 Ultraschall Module defekt sind.
Wäre wirklich schön gewesen, wenn es nur an diesen kleinen Code Unterschieden gelegen hätte. Da mein Code aber das Gleiche macht wie deiner, hatte ich schon befürchtet, dass es nicht geht.
EDIT: Die Fehlersuche geht weiter und der Daumen-Temperaturtest auf der Platine hat ergeben, dass wenigstens bei einem der defekten Sensoren ein Hardwareschaden nahe liegt. Zumindest wird der Chip AAKW links unten verdächtig heiß.
Der andere defekte zeigt diese Auffälligkeit nicht.
Ach, schade. Mir tuts immer weh (manchmal ärgerts mich richtig gründlich) wenn ich Bauteile aus dieser Preisklasse oder höher verliere. Und meine vereinzelten Bemühungen verdächtiges Hühnerfutter zu ersetzen waren nie erfolgreich. Bei den SRF02 könnte man allenfalls noch probieren, zusammen mit dem heilen Stück als Komplementär, ob die im Empfangsmodus (Befehle 86 bis 91 dez, vorzugsweise 87dez .. Zentimeter) mit einem Fremdsender arbeiten oder ob sie im Sendemodus (Befehl 0x5C .. erzeugt 8 Zyklen 40khzTon) was von sich geben. Wie geschrieben - der heile ~02 könnte dann als entsprechender Partner dienen. Später evtl. ein kranker Kollege *gg*Zitat:
... Code ... wirklich 1:1 ... Bei meinem nicht funktionsfähigen SRF02 tut sich leider nichts ...
Noch ne blöde Frage (sorry für die ganzen Vorschläge die dann doch nix taugten) : Was machen die beiden Krücken im TTL-RS232-Modus (GND an Pin4) ? Ist zwar mit 9600 Baud zwar keine wirkliche Empfehlung, aber wenn das ginge . . .
Hallo,
ein Hardwaredefekt ist demzufolge durchaus denkbar. Denn sollte es möglich sein, dass der Sensor sich durch falsche Parametrisierung verläuft, müsste zumindest auch eine Init- bzw. Resetroutine existieren. Dass ein Defekt allerdings durch falsche Datenübertragung geschehen sein soll, will ich nicht hoffen!
Da ich selbst beruflich Steuerungsfirmware schreibe, kann ich mir diesen Fall bei einem „simplen“ Gerät wie den SRF02 nicht vorstellen, dafür sollten (hoffe ich) andere Ursachen verantwortlich sein.
Wie schon hier beschrieben, könntest Du den Defekt möglicherweise eingrenzen, soweit Du Interesse hast weitere Versuche durchzuführen. Interesssant wäre ja vor allem wie dieser entstanden ist!
Wie hier schon erwähnt gibt es die Möglichkeit nur senden oder empfangen zu testen und natürlich auch noch ein paar andere Funktion wie Range Kalibrierung oder Autokalibrierung, letztere wird allerdings bereits beim Start des Sensors ausgeführt. Zur Autokalibrierung steht auch näheres in der Anleitung. Interessant wäre trotzdem ob sich in dem Zusammenhang in den Registern 4/5 noch etwas verändert.
Auch könntest Du während des Messvorganges zyklisch die Firmwareversion abfragen. Solange keine Antwort auf dem I²C kommt, arbeitet zumindest „softwaretechnisch“ der SRF02 den Messvorgang bis Maximalentfernung ab.
Gruß André
Die manuelle Kalibrierung per I2C Befehl habe ich auch schon ausprobiert. Nur Seriellen Mode bisher noch nicht, da ich dazu erst einen Adapter auf RS232 basteln müsste. (MAX232 und Kondensatoren etc). Mit dem Befehl S E3 03 P frage ich eigentlich die Firmware ab. Ich habe auch schon gesucht ob es eine Möglichkeit gibt die Firmware neu zu flashen, aber bisher erfolglos.
Vielleicht häng ich heute mal mein Oszi an den US-Sender/Empfänger und messe ob sich dort noch was tut.