Ich habe hier einen unbekannten, hoch-präisen Sensor mit seriellem Anschluss. 2-Draht für Daten + 2 Mal Spannungsversorgung +/-. Zum Sensor gehört eine Anzeigeeinheit, man kann dem Sensor auch einfache Kommandos schicken, die Kommunkation ist also vermutlich Halb-Duplex. Über die Codierung ist leider überhaupt nichts bekannt. Ich habe ein Oszi angehängt. Zeitbasis am Oszi ist 20us/Div. Auf dem Kabel läuft ein differenzielles TTL Signal ohne separates Clock, aus zwei Paketen (--> Attachment). Das rechte der beiden (das also vom Timing her zuerst kommt) ist vom Bitmuster her immer gleich, die Pause zum 2. Paket ist aber unterschiedlich, es gibt 2 Positionen, siehe 2 Attachments. Dann kommt das Paket das offenbar den Messwert transportiert, es ändert sich stark wenn ich den Sensor bewege. Von dort habe ich mit den Skalenendwerten zwei bekannte stehende Werte: -0,2500 und 5,2500. Werte dazwischen sind schwierig, weil das hoch empfindliche Sensörchen niemals still steht, aber von den beiden Skalenendwerten habe ich stehende Bilder (--> Attachments). Was ich sonst noch sehen kann: wenn ich den Sensor fest einspanne, also möglichst ruhg auf einen Zwischenwert stelle, wo er nur leicht um eine Stelle jittert, springen immer mehrere Bits mit einer gewissen Symmetrie. Ich habe niemals beobachtet, dass nur ein einzelnes Bit sich ändert. Es könnte also sein, dass ein CRC mit im Boot ist, oder dass der Messwert mehrmals gesendet wird. Die beiden letzten "Berge" (links im Screenshot) sind immer unverändert vorhanden, unanhängig vom Messwert. Dann: irgendwo im Bitstom muss die Seriennummer (oder ein Teil davon) kommen, die da wäre 4302033005010704, da die Anzeigeeinheit den Sensor mit seienr Seriennummer identifizieren kann. Dies allerdings ungewiss, da Einheit und Sensor als Einheit geliefert wurden könnte die Seriennumemr auch in die Anzeige eingegeben worden sein, ich halte es aber für wahrscheinlicher dass sie im Datenstrom enthalten ist. Ich habe jetzt ein paar Stunden versucht, die Nuss zu knacken, aber ich finde nicht heraus, wie das Signal codiert ist. Kann mir jemand helfen? Ich setze spontan die beste Flasche Roten aus meinem Keller als Preis ein (Ladenpreis: gut dreistellig €€€) für die Lösung des Rätsels. HG aus Bayern, Armin. P.S. Mehrere Bilder anhängen bzw. welche wieder zu löschen scheint mit der Forums-Software schwer zu fallen, sorry wegen dem Kuddelmuddel.
Angehängte Dateien:
-
Datentelegramm_gesamt_.png
8,1 KB -
Datentelegramm_gesamt_.png
8,1 KB -
Datentelegramm_gesamt_.png
8,1 KB -
Datentelegramm_gesamt_.png
8,1 KB -
Datentelegramm_gesamt__2_.png
9,4 KB -
Wert_-0_2500.png
5,4 KB -
Wert_5_2500.png
4 KB
:
Bearbeitet durch User
Hallo, hast mal versucht einfach einen TTL->serille Wandler(MAX232) anschleissen und dann mal mit PC zu schauen ? bernd
Bernd schrieb: > Hallo, > hast mal versucht einfach einen TTL->serille Wandler(MAX232) > anschleissen und dann mal mit PC zu schauen ? > bernd Hab ich im Moment nicht zur Verfügung. Ich glaube aber nicht, dass die Lösung so einfach ist. Ich habe mit unendlich Geduld den Sensor mal auf 0,00000 getrimmt, und keine auffällige Kette Null-Bits entdeckt.
Kannst du die Daten irgendwie digital hochladen? Am besten irgendwas Herstellerunspezifisches wie CSV oder VCD. Super wäre das komplette Paket, sowohl von den Anschlägen als auch irgendwo in der Mitte, davon dann gerne mehrere damit man dass springen der Werte sieht. Hätte den Vorteil, das man mal ne Software drauf loslassen kann, und nicht alles im Kopf machen muss. Armin L. schrieb: > Dann: irgendwo im Bitstom muss die Seriennummer (oder ein Teil davon) > kommen, die da wäre 4302033005010704, Das sind mindestens 7 Bytes, die müsste man da sehen können, auch von der Länge her.
Ich hab im Moment nur das analoge Oszilloskop, leider. MAX232 um vielelicht durch Probieren zu einer Lösung zu kommen kommen erst Ende der Woche.
:
Bearbeitet durch User
Und der Sensor ist völlig unmarkiert ? Kein Datenblatt ?
Armin L. schrieb: > Ich habe ein Oszi angehängt. Zeitbasis am Oszi ist 20us/Div. Sind die Divisions tatsächlich breiter als hoch? Ich messe eine Bitlänge von ca. 14 Pixeln und eine Division-Breite von ca. 152 Pixeln, macht eine Bitzeit von 1.84 usec und somit knapp 550 kBaud, das wäre schon recht exotisch. Armin L. schrieb: > Auf dem Kabel läuft ein differenzielles TTL Signal ohne separates Clock Könnte RS485 sein. Da der Ruhepegel offenbar etwas unterhalb von 0V liegt und danach immer erst ein Low-Pegel anliegt, misst Du vermutlich am invertierten Ausgang. Der andere dürfte dann eher nach UART aussehen. Interessant ist, dass der Low-Pegel nach dem Einschalten des Transceivers mal recht lange und mal sehr kurz ist - evtl. kannst Du die beiden Devices, die miteinander reden, so an ihrer "Handschrift" erkennen. Hast Du einen Logic Analyzer, Saleae o.dgl.?
Armin L. schrieb: > Ich habe ein Oszi angehängt. Zeitbasis am Oszi ist 20us/Div. Damit würde man auf einen Signaltakt von um die 680kHz kommen. - Was sind das für Signalpegel? - Insbesondere wann tritt der mittlere Pegel auf? Kommt der in Pausen zwischen Datentelegrammen oder gehört der zum Telegramm? - Bist du im Besitz eines kleinen Logikanalysators, um die Daten unkompliziert weiterverarbeitungstauglich aufzuzeichnen? (nach Pegelanpassung)
Armin L. schrieb: > Ich hab im Moment nur das analoge Oszilloskop, leider. Mit Mauszeiger, sehr analog.
Angehängte Dateien:
-
Uebereinandergelegt.png
64 KB
Ein bisschen übersichtlicher einschließlich Versuch einer Taktmarkierung (unten, alle 4 Takte). Nur zwei verschiedene Telegramme ist etwas wenig für ein Dekodier-Puzzle
Armin L. schrieb: > Werte dazwischen sind schwierig, weil das hoch empfindliche > Sensörchen niemals still steht, aber von den beiden Skalenendwerten habe > ich stehende Bilder (--> Attachments). Hilfreich wären ein paar Zwischenwerte aber trotzdem. Kannst du mit dem Sensor Einzelmessungen durchführen? Wenn ja, dann bekommst du zwar krumme und leicht zufällige Messwerte, aber du kannst zu jedem Messwert ein Oszillogramm aufnehmen, das genau die Bits zeigt, die zu diesem Wert führen. Wenn die Messwerte automatisch fortlaufend übertragen werden, können die Oszillogramme natürlich nicht mehr eindeutig den angezeigten Messwerten zugeordnet werden. Aber auch Oszillogramme mit einer ungefähren Angabe des übertragenen Messwertes wären schon besser als gar nichts.
Verstehe ich nicht ganz. Du sagst es sind 2 Leitungen im Halb-Duplex, also nehme ich an diese sind Differenziell? Wenn ja, kannst du beide Pole miteinander Messen? Sind diese schön Symmetrisch? Welche Spannungen sind vorhanden? Macht es einen Unterschied mit einem Abschlusswiederstand?
Ist es möglich das Profibus verwendet wird?
Armin L. schrieb: > Ich habe hier einen unbekannten, hoch-präisen Sensor Nicht sehr glaubhaft. Der Sensor ist unbekannt, aber es ist bekannt, dass er hochpräzis ist. Wen willst du hier verarschen?
Schnell die paar Infos für die Paranoiker: das Oszilloskop ist ein "Bitscope". Analoge Elektronik, Anzeige am PC Bildschirm. Daher kommt die Verzerrung des Rasters und der Mauscursor ist vom Screenshot-Tool. Signalspannung ist TTL: 5V P-P, Ruhepegel bei annähernd 0V. Das Oszi habe ich zwischen die beiden Datenleitungen geklemmt. Wer da + und - ist kann ich natürlich nicht sagen, es ist nix dazu dokumentiert wie der Anschlussstecker beschaltet ist. Wenn es der Sache hilft, und so üblich ist, drehe ich den Anschluss gerne um, damit der Ruhepegel oberhalb der horizontalen Achse dargestellt wird. Klar weiß ich, von wem der Sensor ist, es steht zwar nichts drauf, aber auf dem Interface zur Anzeigeeinheit steht sein Name, und es gibt auch ein Datenblatt, aber darin steht exakt null zum Übertragugsprotokoll. Ich habe den Hersteller nicht genannt, weil ich schon über seinen Support an die Infos heran wollte, man hat sie mir verweigert. Ich wollte euch nicht öffentlich dazu aufrufen mir zu helfen, die "Firmengeheimnisse" eines Weltmarktherstellers "auszuspionieren", selbst wenn es nur die Info ist, dass man die Übertragung nach irgendeiner Weltnorm macht. Krumme/hohe Baudrate ist nicht unwahrscheinlich, da er mit einer extrem hohen Messrate wirbt, ich kann morgen gerne nachsehen wie viel das ist. Screenshots von weiteren Paketen kann ich beliebig viele machen. Morgen bekomme ich Zugang zu einem einfachen Logic-Analyser, mal sehen ob der etwas ausrichten kann. Anzeige und Oszillogramm passen vom TIming her nicht hundertprozentig zusammen, erstens sind es verschiedene Geräte, und weil die Anzeigeeinheit offenbar ein wenig trickst und den Jitter herausrechnet, damit die letzten Stellen nicht wild in der Gegend herumspringen. Die Bits auf dem Oszillogramm springen munter, die Anzeigeeinheit steht wie angenagelt. Da sie außerdem einen Haufen Optionen anbietet, die Messwerte zu mitteln, und die Anzeige wenn ich den Sensor von Hand auslöse auch merkbar den Datenpaketen hinterher hinkt bekomme ich ein zuordenbares Bild nur an den beiden Endpunkten des Messwegs, weil hier die Werte lang genug stehen bleiben dass ich die Anzeige ablesen und einen Screenshot anfertigen kann. Hier jittert der Sensor auch nicht. Profilbus ist ebenso möglich wie jedes andere serielle Bussystem. Wie gesagt, im Datenblatt zum Sensor steht kein Wort zur Datenverbindung. Er funktioniert ja mit den fertigen Geräten des Herstellers. Für Integration in diverse Bussysteme kann man zum Sensor passende Interfaces dazubestellen, aber ich will den Sensor direkt lesen. Halb-Duplex ist eine Vermutung, weil die Anzeigeeinheit dem Sensor einfache Kommandos schicken kann, man kann z.B. eine LED an- und ausschalten um ihn in einer Installation mit gleichartigen Sensoren finden zu können. Ich meinte dann immer einen Bitsprung im kleinen Paket (rechts) gesehen zu haben, aber das Bild steht nur einen Sekundenbruchteil weil ich das Oszi nicht darauf triggern kann. Ich vermute (!) daher, dass das kleinere Paket eine Anfrage nach dem nächsten Messwert durch die Anzeigeeinheit sein könnte. Ich denke, wenn ich den Analyser zum Laufen bekomme sieht man nochmals mehr. Noch was vergessen? Ich glaube nicht ... dann jetzt gute Nacht, und man liest sich morgen wieder, hoffe ich. Armin.
:
Bearbeitet durch User
Das Protokoll kenne ich gut, habe es selbst schon implementiert. Möchte hier nichts genaues dazu sagen, um keinem Weltmarkthersteller auf den fuß zu treten.
Lass die Katze aus dem Sack, Welcher Hersteller und was wird so präzise gemessen?
Armin L. schrieb: > Schnell die paar Infos für die Paranoiker: das Oszilloskop ist ein > "Bitscope". Die Software kann selbstverständlich auch die Abtastwerte aufzeichnen.
Armin L. schrieb: > Klar weiß ich, von wem der Sensor ist, es steht zwar nichts drauf, aber > auf dem Interface zur Anzeigeeinheit steht sein Name, und es gibt auch > ein Datenblatt, aber darin steht exakt null zum Übertragugsprotokoll. Trotzdem solltest du diese Infos den Helfern nicht vorenthalten. > Ich wollte euch nicht öffentlich dazu aufrufen mir zu helfen, die > "Firmengeheimnisse" eines Weltmarktherstellers "auszuspionieren Das hast du aber getan. Jetzt stehe auch dazu und mache Nägel mit Köpfen.
Ok, ich glaube das Protokoll analysiert zu haben, zumindest die Teile davon, die in den geposteten Screenshots zu Anwendung kommen. Wenn du weitere Screenshots (mit anderen Messwerten) postest, kann ich daraus den Messwert herauslesen und damit meine Hypothese prüfen. Armin L. schrieb: > Ich habe den Hersteller nicht genannt, weil ich schon über seinen > Support an die Infos heran wollte, man hat sie mir verweigert. Ich muss mich jetzt also entscheiden, ob ich deinen Wunsch erfülle, die herausgefundenen Protokollinformationen zu veröffentlichen, oder den Wunsch des Herstellers, genau dies nicht zu tun. Ich kenne weder dich noch den Hersteller des Sensors. Wem von beiden sollte ich also einen Gefallen tun? Außerdem müsste noch die Rechtslage bzgl. des Reverse-Engineering für den konkreten Fall geklärt werden. Vielleicht kommt ja Percy gleich um die Ecke ;-) Armin L. schrieb: > Ich habe jetzt ein paar Stunden versucht, die Nuss zu knacken, aber ich > finde nicht heraus, wie das Signal codiert ist Vielleicht ist es das Beste, wenn du dich noch ein paar weitere Stunden damit beschäftigst. Nur so viel als Hinweis: Es handelt sich um ein sehr einfaches Kodierungsschema. Auf den dekodierten Wert muss am Ende noch eine einfache Rechenoperation mit einer "magischen" Konstante angewandt werden, um auf den angezeigten Messwert zu kommen. Der Wert dieser Konstanten lässt sich aber schon aus den beiden gesposteten Beispielen eindeutig ermitteln.
:
Bearbeitet durch Moderator
Yalu X. schrieb:
Ich habe Dir die Info, von welchem Hersteller der Sensor kommt, per Mail
zugesendet. Ich denke aber, ihn zu veröffentlichen ist nicht nötig, Nuss
ist Nuss, und so lange man den Hersteller nicht nennt, kann sich keiner
drüber aufregen.
Wenn ich außerdem Recht habe mit der Annahme, dass es ein
Standatd-Protokoll ist, darf man das ja ruhig analysieren, oder? Das
Protokoll der Bitschicht zu kennen heißt ja nicht, dass man die
Bedeutung der Bytes offen legen muss.
Armin.
Worum geht es denn, um die Steuerung einer Massenvernichtungswaffe? Ich denke schon, dass die Helfer erfahren sollten, womit sie sich da befassen. Denn das kann durchaus neben der rechtlichen Frage auch eine Gewissensfrage sein.
Stefan ⛄ F. schrieb: > Worum geht es denn, um die Steuerung einer Massenvernichtungswaffe? > > Ich denke schon, dass die Helfer erfahren sollten, womit sie sich da > befassen. Ich verstehe Yalu. Wir leben im Paradies Abzockanwälte. Ich sehe aber - so lange der Hersteller nicht genant wird, und nur der Bitstrom decodiert wird, ohne die Bedeutung der Bytes zu dokumentieren, kein Problem. Armin.
Sieht fuer mich ziemlich aehnlich aus wie ein SENT Datagramm (SAE J2716). Das uebertraegt so Sachen wie Seriennummern langsam ueber viele Frames nacheinander, hat 1-2 lange Pulse am Anfang, normalerweise 7-9 kurze Pulse in der Mitte und wird gerne bei neuen Sensoren hergenommen.
Es gibt doch Oszi's die so ein serielles Signal decodieren können und das Ergebnis als Klartext ausgeben. Das geht eigentlich recht ordentlich. Auf diesem Weg habe ich das Protokoll eines Anzeigemoduls entschlüsseln können.
flip schrieb: > Das Protokoll kenne ich gut, habe es selbst schon implementiert. Möchte > hier nichts genaues dazu sagen, um keinem Weltmarkthersteller auf den > fuß zu treten. Gut, deine Entscheidung. Aber ob man dermaßen gefügig sein muss ist eine andere Frage. Du bist hier anonym in einem Forum, glaubst du ernsthaft dass der Hersteller jetzt rechtliche Schritte einleitet, dich zurückverfolgt und vor Gericht zerrt? Im Endeffekt ist es wahrscheinlich ein lächerlicher Drucksensor/Wägezelle/Linearaufnehmer oÄ. Ich würde einmal raten: Ein Messtaster von Heidenhain. Also wahrscheinlich willst du so einen Taster in ein eigenes System einbetten, wüsste nicht inwiefern das ein Problem sein sollte. Vorallem heutzutage sollten wir gewissen Firmen viel öfter und fester ordentlich auf die Füße treten.
Anarchodekodierer schrieb: > Vorallem heutzutage sollten wir gewissen Firmen viel öfter und fester > ordentlich auf die Füße treten. Solltest du unbedingt machen und hier danach berichten, wie hoch die Prozesskosten waren, die du deinem und dem gegnerischen Anwalt bezahlen musstest. Vorabinformationen zur Kostenlage gibt es in den einschlägigen Juraforen. > ... Du bist hier anonym in einem Forum ... Selbst mit TOR & Co. ist das u. U. fragwürdig.
Armin L. schrieb: > Ich wollte euch nicht öffentlich dazu aufrufen mir zu helfen, die > "Firmengeheimnisse" eines Weltmarktherstellers "auszuspionieren", selbst > wenn es nur die Info ist, dass man die Übertragung nach irgendeiner > Weltnorm macht. Dann lies dir mal das seit dem 24.04.2019 geltende Gesetz zum Schutz von Geschäftsgeheimnissen (GeschGehG) §3 (1) Nr. 2 durch. Reverse Engineering frei verfügbarer Geräte ist explizit zulässig. https://www.gesetze-im-internet.de/geschgehg/__3.html
Wolfgang schrieb: > ngineering frei verfügbarer Geräte ist explizit zulässig. Eben, man ist in Schlandland einfach zu hörig und schüchtern. Armin L. schrieb: > Weltmarktherstellers Alleine wenn ich solche Fantasieworte schon höre könnte ich Bits und Bytes kotzen, jeder Hipster Autist der Heilsteine verkauft ist ein "Weltmarkthersteller" weil er eben für den Weltmarkt herstellt. Aber manche in diesem Land sagen ja auch noch Frau Post/Regierungsamtsmeister zu der Gattin von irgendeinem unwichtigen Bürowicht und fühlen sich gut dabei. Gibt ja in DE sogar noch die vons und zu´s. Hier ist es halt so: Mmmh ich weiß nicht, darf ich den Namen jetzt sagen oder komm ich dann ins Arbeitslager? mimimi Das ist auch der Grund warum bei uns so viel an Betrug und Kundenverarsche möglich ist, wenn alle schon ins Zittern kommen und einen Bückreflex weil das ist ja ein "Weltmarkthersteller" da muss ich ganz artig sein, sonst kommt die Gestapo. Sonst wäre vieles wie zB. der Abgasskandal undenkbar, das lässt man sich in den USA zB. nicht so einfach gefallen. Die meisten Unternehmen in unserer Hemisphäre sind abgehoben, man bekommt keine Infos/Preise oder wird gar nicht erst beliefert als kleiner Fisch oder gar Privaterson. Gut, kaufe ich halt in USA oder China. Man denke an die alten Appnotes von National etc. in denen noch die Adresse/Telefonnummer von Leuten wie Bob Pease stand, ja man konnte direkt anrufen und fragen stellen. In Deutschland undenkbar, da ruft man bei xy an und kommt bei einer tschechischen Zeitarbeitsfirma/Callcenter heraus. Wolfgang schrieb: > Reverse > Engineering frei verfügbarer Geräte ist explizit zulässig. Ja sicher ist es das, sonst könnte man ja jeden Konkurenten als "Fälscher und Nachbauer" bezeichnen und sich ein Monopol erklagen. Nicht umsonst heißt es: "Ein Geschäftsgeheimnis darf insbesondere erlangt werden durch eine eigenständige Entdeckung oder Schöpfung" Ohne diesem Satz gebe es defacto keine neuen Unternehmen in irgendeiner Branche.
Führt die Diskussion bitte nicht mit mir. Als erstes klopft der Anwalt ja beim Betreiber des Forums an und nicht bei mir. Außerdem sehe ich immer noch nicht, was das Dekodieren des Bitstroms mit der Info, wer der Hersteller des Sensors war, zu tun hat. Von Rechtsstreitigkeiten mit Konzernen rate ich jedem der es hören will ab, selbst wenn Du nach 5 Jahren oder so Recht bekommst bist Du entweder ein nervliches Wrack oder pleite oder beides. Aber der Forums-Admin hat alle Infos von mir bekommen, er kann das gerne posten wenn er das für richtig hält. Aber wie man an seinem Besipiel sieht, ist das Risiko komplett unnötig. Was er ausgetüftelt hat, staht nicht im Prospekt. Armin.
Armin L. schrieb: > Außerdem sehe ich immer noch nicht, was das Dekodieren des Bitstroms mit > der Info, wer der Hersteller des Sensors war, zu tun hat. Weil man damit Informationen finden kann oder gar schon hat.
Nein!
> Weil man damit Informationen finden kann oder gar schon hat.
Er hatte seine Teil-Lösung bereits, bevor ich ihm die Info geschickt
habe.
Armin.
Armin L. schrieb: > Er hatte seine Teil-Lösung bereits, bevor ich ihm die Info geschickt > habe. Ja das sehe ich. Die Bitte um weitere Infos ist allerdings älter und du wolltest wissen, warum darum gebeten wurde. Zwischenzeitlich hat sich das erledigt, ist klar.
Wolfgang schrieb: > Dann lies dir mal das seit dem 24.04.2019 geltende Gesetz zum Schutz von > Geschäftsgeheimnissen (GeschGehG) §3 (1) Nr. 2 durch. Reverse > Engineering frei verfügbarer Geräte ist explizit zulässig. Das betreffende Gerät/Sensor ist aber nicht frei verfügbar und befindet sich auch nicht im besitz der angefragte Thread-Rezipenten. " ... sich im rechtmäßigen Besitz des Beobachtenden, Untersuchenden, Rückbauenden oder Testenden befindet und dieser keiner Pflicht zur Beschränkung der Erlangung des Geschäftsgeheimnisses unterliegt;"
Anarchodekodierer schrieb: > Ohne diesem Satz gebe es defacto keine neuen Unternehmen in irgendeiner > Branche. Was hat das mti Punkt 2 (..., Untersuchen, ...) zu tun?
Wir hatten einen konkreten Tip, dazu kam noch keine Reaktion: https://en.wikipedia.org/wiki/SENT_(protocol) da steht allerdings "one way" und "requires three wires" (signal, supply, GND)
Angehängte Dateien:
-
-0_0501.jpg
230 KB -
4_2772.jpg
230 KB -
2_6321.jpg
230 KB
Um zum Thema zurück zu kommen.... hier nochmal ein paar Oszillogramme von anderen Messwerten (kleine Abweichungen der letzten Stellen sind möglich wegen Jitter) vom Sensor ... Messwerte in der Anzeige waren: -0,0501 4,2772 2,6321 Armin.
Christoph db1uq K. schrieb: > Wir hatten einen konkreten Tip, dazu kam noch keine Reaktion: > https://en.wikipedia.org/wiki/SENT_(protocol) > da steht allerdings "one way" und "requires three wires" (signal, > supply, GND) Es sind definitiv vier Leitungen. +,-,2xDaten. Bin sie mit dem Oszi abgefahren, DC 7V ist klar zu sehen, und von jeder der beiden "DC Leitungen" zu einer der beiden "Signalleitungen" bekomme ich die Bits aufs Oszi, aber nur halbe Spannung und etwas verzerrt. Zwischen den beiden Datenleitungen angeklemmt ist das Signal sauber und 5V P-P, siehe Screenshots. Daher meine Annahme, dass ich es mit einem Differenzsignal mit TTL Pegel zu tun habe. Und es kann nicht one way sein, weil man wie gesagt Befehle von der Anzeigeeinheit zum Sensor senden kann, und der auch drauf reagiert, und ich das Bit, welches das auslöst, kurz über den Bildschirm huschen sehen kann. Bisher scheint mir Yato in Führung zu liegen :-) Armin.
Christoph db1uq K. schrieb: > Wir hatten einen konkreten Tip, dazu kam noch keine Reaktion: > https://en.wikipedia.org/wiki/SENT_(protocol) > da steht allerdings "one way" und "requires three wires" (signal, > supply, GND) Autsch, das hatte ich - gefangen genommen von Yalus Leistung - erst mal nicht konsequent nachverfolgt, entschuldige. Die Ähnlichkeit ist in der Tat frappierend. Vielleicht hat "mein" Hersteller ja das Bitprotokoll übernommen, und macht auf der physikalischen Schicht sein eigenes Ding. Ich werde allerdings eine Weile brauchen um das zu verifizieren, da es sich beim Spielen mit dem Sensor um meine Freizeit handelt kann ich wenn dann nur Abends und am WE daran arbeiten. Yalu, was meinst Du, ist die Spur heiss? Armin.
:
Bearbeitet durch User
Armin L. schrieb: > das Oszilloskop ist ein "Bitscope". Damti kann man sehr einfach Daten aufnehmen. Dann müssen alle die helfen wollen nicht Pixel zählen sondern können das in z.b. Sigrok selber anschauen und versuchen zu dekodieren. So sehr reizt mich das Problem dann doch nicht, und dein Wein erst recht nicht. https://www.bitscope.com/software/dso/guide/2.5/?p=recorder Christoph db1uq K. schrieb: > Wir hatten einen konkreten Tip, dazu kam noch keine Reaktion: > https://en.wikipedia.org/wiki/SENT_(protocol) > da steht allerdings "one way" und "requires three wires" (signal, > supply, GND) SENT scheint eine fancy PWM zu sein, hier sind aber weder Pulse noch Pausen konstant, scheinen also beide unabhängig Information zu beinhalten. Auch den Sync Puls kann ich nicht wirklich erkennen. Könnte trotzdem über die Längen kodiert sein, aber in Pixel zählen investiere ich keine Zeit, da müssen schon echte Daten ran. Tippe eher auf ne Art RS-485.
Yalu hat das Problem souverän gelöst. Vielleicht postet er die Auflösung, die er mir geschickt hat hier rein? Ich habs bisher nicht geprüft, aber die Lösung ist so detailiert und schlüssig abgeleitet dass es eigentlich stimmn muss. Mal sehen, ob er rot oder weiss bevorzugt :-) Ich danke euch fürs Mitmachen und das Knacken der Kopfnuss! HG aus Bayern, Armin.
Schade. Menschen, die nichts Preisgeben wollen gehört nicht geholfen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.