Wir haben hier ein Messgerät, dass der Messung von Baufeuchte mit Hilfe eines 2.4-GHz-Radarsensors dient. Dem Sensor ist eine externe Elektronik vorgeschaltet, die der Kommuniktion mit einer Anzeigeeinheit dient. Es wird nur eine Data-Leitung bidirektional verwendet.
Kann hier jemand erkennen, ob der Verlauf irgend einem bekannten Protokoll entspricht? Simples RS232 wird es wohl eher nicht sein.
Um den genauen Inhalt kümmern wir uns später, ich hätte nur gerne mal eine erste Einordnung. Das "Aktivierungs-Paket" von der Leseeinheit sieht (bis auf Details) genau so aus. Klassisches OneWire ist es doch nicht, oder?
Mich irritiert vor Allem die Absenkung kurz vor den Daten ...
Danke für Tips.
@Admin: Beim ersten Bild hab ich wohl suboptimal skaliert. Ich dachte, wenn ich den Beitrag nochmal bearbeite, wird es ersetzt. Langer Rede kurzer Sinn, das erste kann weg. Sorry.
Was soll man mit so einem Screenshot anfangen? Kannst du nicht gleich was zum Timing dazuschreiben? Und die Absenkung des Pegels wird daher kommen, dass jemand aktiv den Pegel einstellt, bevor die Aussendung beginnt. Die nächste Salamischeibe wäre nun, um welches Gerät von Trotec es sich handelt (SDI 1?). Warum muss man allen Fragenden immer jede Information aus der Nase ziehen?
p.s.: es wäre auch interessant, was das Gerät bei dieser Bitfolge anzeigt.
Am 5-Pol-Anschluss des T3000 lassen sich verschiedenste SDI-Sensoren mit integrierter Messelektronik anschließen...Durch die intelligente Technik erkennt das T3000 beim Wechseln der SDI-Sensoren selbsttätig, welcher Sensor gerade angeschlossen ist.
Das Bild hat jemand mit dem Handy gemacht, der nicht weiss, dass der Oszi auch Bilder direkt speichern kann, ich bin z.Zt. nicht vor Ort. Mit etwas Nachbearbeitung kann man nun das Divgrid ahnen. Horzontal 800 Mikrosekunden, vertikal 2V pro Div.
Es ist die Kommunikation eines älteren Trotec T2000 mit dem "Mikrowellen"-Feuchtesensor, genau genommen die Antwort des Sensors. An dem "SDI"-Anschluss wird nur eine von 5 Leitungen für Daten benutzt, zwei für Spannung, die anderen beiden sind auf der Platine nichtmal angelötet.
Auf der Platine sieht man links den SDI-Anschluss, rechts die drei Kabel zum "Radarsensor", Typenschild: "Innosent GmbH IPS-149", wobei der Sensor tatsächlich von der Firma LUFFT stammt, steht auch auf der Platine ...
Ich lass morgen nochmal bessere Oszi-Bilder machen.
Wie kommst du auf die Frequenz?
Das Datenblatt sagt etwas anderes.
Ja, das sagt etwas anderes. Zuvor fand ich dies hier (s. Bild). Hab es aber nur noch als Screenshot. Ist wahrscheinlich ein Tippfehler oder Missverständnis meinerseits. Auf der Platine im Griffstück taucht der Namen "Lufft" auch auf.
Jetzt fällt mir aber noch ein Unterschied auf: Im Screenshot geht es um IPS149, beim Trotec um IPS-146. Naja, war ein langer Tag ... sorry.
Nachtrag: Die ersten beiden Bytes wiederholen sich 1x.
Hmmm ... sind das 9600Bd?
Ich lese 02 00 02 00 55 90 B0 03.
LG, Sebastian
Wenn wir das seriel sauber lesen können, lass ich Testreihen machen, mit unterschiedlich feuchten Medien vor dem Sensor. Dann sollten Bytes gleich bleiben (Sensor-Kennung?) und andere sich verändern (Messwerte, evtl. "raw") ...
Das in den FCC Dokumenten ("User Manual 2.4 GHz Radar Sensor IPS-149") beschriebenen Protokoll ("Binary protocol (Chapter 10.2)") passt zu dem obigen Beispiel, die CRC stimmt ebenfalls:
1
02 00 02 00 55 90 B0 03
2
3
STX ID CNT CMD D0 CRC_L CRC_H ETX
Siehe auch "9.2.3.1 Request of data from IRS21 to host"
Siehe auch "9.2.3.1 Request of data from IRS21 to host"
Damit ist es also Zufall, dass sowohl das 1. und 3., als auch das 2. und 4. Byte gleich sind, d.h. es handelt sich nicht um eine Wiederholung im Sinne des Protokolls ;-)
Könnte es sein, dass Trotec gar keine Lust hatte, extra ein eigenes Protokoll zu erfinden? Im Umfeld der Firma Lufft taucht immer wieder die Bezeichnung "SDI-12" auf ...
Es ist doch eigentlich ziemlich offensichtlich was das passiert: Der NEC 78K auf der Platine setzt das Protokoll des 2.4 GHz Radarsensor in das SDI Protokoll zum Trotec T2000 Messgerät um.
Das Protokoll des 2.4 GHz Radarsensor ist in den Dokumenten von der FCC beschrieben, mehr zum SDI Protokoll weiß man sobald man davon einen Mitschnitt hat (und ob es tatsächlich SDI-12 ist).
So wie es aussieht, ist das SDI-12-Protokoll selbst in der Arduino-Welt schon längst ein "alter Hut" für kommerzielle Umwelt- und Wetter-Sensoren aller Art! Entsprechende Libs und Projekte gibt es zuhauf. Falls das wirklich passt ... wundervoll!
Auch die Hardware wird immer verständlicher: asychrones serielles Protokoll auf EINER Leitung (bei Arduino auf Basis SoftSerial).
Das Umschalten des jeweiligen Pin zwischen Input und Output erklärt dann auch die leichte Pegelverschiebung im Oszillogramm, vermutlich durch Zuschalten eines Pullup beim Lesen ...
So wie es aussieht, ist das SDI-12-Protokoll selbst in der Arduino-Welt
schon längst ein "alter Hut" für kommerzielle Umwelt- und
Wetter-Sensoren aller Art!
Liegt vielleicht daran dass es SDI-12 seit 1988 gibt...
Auch der ist leider untauglich.
Das muss in hoher auflösung mit Trigger abgefahren werden und gfs hintereinander kopiert werden.
Dann nimmt man sich die Zeitauflösung und schätzt den Takt
Dann nimmt man die Nullen und Einsen auseinander und schreibt sie hier hin.
Was soll das bringen? Das Protokoll des Lufft IPS-149 ist doch bereits geklärt. Wenn man da noch mehr mitschneiden will hängt man am einfachsten einen UART auf USB Adapter dran (nach geeigneter Pegelanpassung).
kein Grund gleich pampig zu werden.... ach ja, das war ja hier im Forum Programm.
Also dann jetzt nochmal zur Frage "serielles Sensor-Protokoll erkennen?". Geht das auch in ganzen Sätzen? Der Threadersteller hätte sicherlich netter und sinnvoller geantwortet ;)
das ist Ansichtssache, ob das pampig ist oder nicht, falls der Fragesteller Interesse an Infos hat, wird er sich wohl melden. Du warst an diesem Thread offenbar bisher nicht beteiligt, daher gehe ich davon aus, dass Du hier einfach nur rumtrollen willst.