Hallo. Ich will das UART Protokoll zwischen einem Handheldgerät und dessen Akku analysieren. Dafür würde ich gerne wissen, was man für einen LA braucht, um das zu tun. Ich weiß dass es günstige Analyzer gibt, weiß aber nicht, ob die bei hohen Baudraten noch was taugen, oder ob man da doch was besseres = schnelleres braucht. Ich kenne die Baudrate der UART Kommunikation nicht genau, ich dachte es wäre 9600, aktuell sieht es aber eher nicht mehr danach aus als ob dem so wäre.
Espressif schrieb: > Ich kenne die Baudrate der UART Kommunikation nicht genau, ich dachte es > wäre 9600, aktuell sieht es aber eher nicht mehr danach aus als ob dem > so wäre. Dann solltest du das klären, z.B. mit einem Oszi. Für den Einsatz eines LA musst du sowieso die Logikpegel kennen.
Gibt es dazu irgendwas wo man lesen kann wie man das mit dem Oszi macht? Also ich meine die Baud eines UART Signals analysieren?
Die höchste Rechteckfrequenz, die auftreten kann, ist die Hälfte der verwendeten Baudrate. Sieh Dir also an, was auf den beiden Datenleitungen passiert. Wieso eigentlich ein neuer Thread zum Thema? Dein "Handheldgerät" war hier doch letzte Woche schon unterwegs.
Espressif schrieb: > Ich will das UART Protokoll zwischen einem Handheldgerät und dessen Akku > analysieren. Dafür würde ich gerne wissen, was man für einen LA braucht, > um das zu tun. Ich weiß dass es günstige Analyzer gibt, weiß aber nicht, > ob die bei hohen Baudraten noch was taugen, oder ob man da doch was > besseres = schnelleres braucht. Diese billigen "24MHz 8Ch" Teile bei Amazon und anderen sind für übliche UARTs bis 1MBit/s auf jeden Fall schnell genug. Sie können aber nur normale Logiksignale verarbeiten - bei RS232, RS422, RS485 und ähnlichem musst Du noch passende Transceiver davorhängen. fchk
Vermutlich willst du mithören, das über die serielle Verbindung geht. Dafür reicht ein COM-Port an einem PC, auch so ein USB-COM-Port Adapter. Du schließt RX vom PC parallel an die Datenleitung an und kannst dir mit einem Terminalprogramm (z.B. Putty) den Datenverkehr ansehen. Um den Verkehr in beiden Richtungen gleichzeitig anzuschauen brauchst du 2 COM-Ports oder Adapter. Den Logikanalysator brauchst du nur, wenn du irgendwelche Störungen vermutest. Und auch da reicht meist ein Oszi. Bernd
Bernd schrieb: > Den Logikanalysator brauchst du nur, wenn du irgendwelche Störungen > vermutest. Und auch da reicht meist ein Oszi. Klar, ein Gerät für mehrere hundert Euro reicht, wenn es ein für den TO locker geeigneter Logikanalysator für 10 Euro auch tun würde. Den Pegel kann man mit einem Multimeter bestimmen, wenn man weiß, was man tut. Die Baudrate sieht man dem Signal auf dem LA an. Ein paar Grundlagenkenntnisse zur asynchronen seriellen Übertragung wären allerdings von Vorteil.
Bernd schrieb: > Dafür reicht ein COM-Port an einem PC, auch Soweit war ich schon, aber so finde ich die Baudrate nicht raus, und 9600 ist wahrscheinlich wie ich mittlerweile vermute falsch. Wenn die schlau waren, haben die die Baudrate auf was ungewöhnliches gesetzt, so kriegt man schonmal die meisten Bastler usw. los, weil dann nur Kauderwelsch ankommt beim mitlesen, so wies bei mir ja auch zu sein scheint.
Frank K. schrieb: > musst Du noch passende Transceiver davorhängen. Und was für Transceiver sind passende? Ich seh da schon kommen, ich werde irgendwoher ein gescheites Oszi / Logikanalyser (Gibt ja Dinger die beides können) beschaffen müssen. Ich weiß ja noch nicht mal ob das überhaupt RS232 oder sonstwas ist, und die Messgeräte sind da meine Augen, wennste nix siehst kannst auch nicht weiterkommen, auch für Zukunftsprojekte wird sich die Anschaffung eines solchen Gerätes lohnen. Wenn man jetzt mal nicht so auf den Preis achtet, was wären denn gute Geräte dahingehend die dann auch was professioneller sind, d.h. nichtmehr das totale Einsteigersegment? Es kann dann in der Zukunft auch sein dass ich damit auch mal an Schaltungen in Rechnern, usw. ran will. Da wäre natürlich ein Oszi mit eingebautem Logikanalyser sinnvoll.
DerEgon schrieb: > Wieso eigentlich ein neuer Thread zum Thema? Weil es im letzten Thread darum ging das Mitgeschnittene zu analysieren, das sich jetzt aber wohl als völlig unbrauchbar erwiesen hat. Daher jetzt erstmal Werkzeugbeschaffung, Oszi und LA stehen bei mir eh schon lange auf der Liste, dann aber vielleicht gelich ordentliche Geräte mit denen man später auch an komplexere Sachen ran kann.
Espressif schrieb: > Ich will das UART Protokoll zwischen einem Handheldgerät und dessen Akku > analysieren. Dafür würde ich gerne wissen, was man für einen LA braucht, > um das zu tun Schon wieder ? Gar keinen. Espressif schrieb: > Oszi und LA stehen bei mir eh schon lange auf der Liste, Du willst einfach nur kaufen. Kauf ein Eis.
Espressif schrieb: > Ich weiß ja noch nicht mal ob das überhaupt RS232 oder sonstwas ist Dann kläre das doch erst mal, bevor du unpassende Hardware kauft. Mit einem Oszilloskop (ab 30 Euro) kriegt man das wohl an schnellsten hin, aber es geht auch anders. Du könntest z.B. mal damit anfangen, die Ruhepegel zu messen.
Espressif schrieb: > jetzt erstmal Werkzeugbeschaffung, Oszi und LA stehen bei mir eh schon > lange auf der Liste, dann aber vielleicht gelich ordentliche Geräte mit > denen man später auch an komplexere Sachen ran kann. Meine Güte! Um die Baudrate auszumessen sollte bereits ein ein ganz einfaches, mittels Soundkarte improvisiertes Oszi genügen. Im Datenstrom suchst Du Dir die schmalsten Rechteckpulse heraus. Deren Breite (in Sekunden) ist dann genau der Kehrwert der Baudrate des Signals. Zur Analyse der Kommunikation zweier, über RS232 kommunizierender Geräte, solltest Du zwei RS232-Empfänger verwenden, da Du beide TxD-Signale parallel aufzeichnen solltest. Übrigens sind die Baudraten der USB-Usarts von FTDI in einem weiten Bereich einstellbar und sollten sich somit auch an krumme Baudraten anpassen lassen. Zumindest unter Linux geht das problemlos. Ob und, wenn ja, wie das mit Mikey$oft funktioniert, kann ich nicht sagen. Es gibt dann gerne noch weitere Gemeinheiten. So kommunizieren die Hameg-Messgeräte der 81xx-Serie über eine RS232-Schnittstelle mit 312,5 kBd und 9 Datenbits. Das 9. Bit unterscheidet zwischen "Nutzlast" und internen Kommandos. Das alles ließ sich problemlos mit meinem alten HM205-2 analysieren. Grüßle, Volker
Physiklehrer des nächsten Gymnasiums... Da wird deren Scope mal endlich genutzt Soundinput in den PC und FFT. Oder gleich ein AD Analog Discovery.
Ein Oszi ist gut, um "1 Bit/Byte" zu analysieren. Flanksteilheit, Pegel, Baudrate, Symmetrie. Ein LS-Analyzer ist gut, mehrere Bytes zu beobachten. Ein LS-Analyzer ist unschlagbar, um geclockte Signale zu beobachten, da Doppelimpulse oder falsche Flanken oftmals nur schwer (mit viel Erfahrung) am Oszi triggerbar sind, während ein LS genau dafür gemacht ist mit "beliebig" langen Datenreihen davor und danach
A. S. schrieb: > Ein LS-Analyzer ist unschlagbar, um geclockte Signale zu beobachten, da > Doppelimpulse oder falsche Flanken oftmals nur schwer (mit viel > Erfahrung) am Oszi triggerbar sind, während ein LS genau dafür gemacht > ist mit "beliebig" langen Datenreihen davor und danach Also doch besser Logicanalyser?
Espressif schrieb: > Also doch besser Logicanalyser? Erstmal müssen die Signalpegel klar sein, dann kann man den passenden Logic Analyzer oder Adapter besorgen.
Stefan ⛄ F. schrieb: > Espressif schrieb: >> Also doch besser Logicanalyser? > > Erstmal müssen die Signalpegel klar sein, dann kann man den passenden > Logic Analyzer oder Adapter besorgen. Geht das mit sowas: https://www.ebay.de/itm/334494398647?hash=item4de16b78b7:g:D2EAAOSwkXdiw~Kj&amdata=enc%3AAQAHAAAA4JYJBNLP%2Fsa2yzTsAPxXfvRlzwfUjTdU%2FlGowC1LY1wvjQKPL5iMCbAYps6F%2BUb11yUnhde4s0nEOcYt9YAt6an7ilh6bY%2FxC3m1UNAp7ngV9Wmn9yUW3Guwj23g1%2FGATbNE8kETW%2FF2zNFq9fhFEcOAoE13gXbare%2BsDbm2P0sKEmGYfm3LZqpOGSQ9VCIsGgZSsFi6tuGhqwkOUzhqlFkgkmrIMk%2BENHIq3EGhejIo9VUfp2irkGDQf15%2Bd5d%2FFqP5zgffdF7xbnBskeQszX2MMnihXzWZX%2Bgaua%2FT1DOG%7Ctkp%3ABk9SR-zci7XdYA Schon?
Espressif schrieb: > Also doch besser Logicanalyser Nein. Du hast keine geklockten (synchrone) Signale. Pegel und baudrate herausfinden und dann mitlesen am PC. Terminalprogramm oder was eigenes. Logikanalyzer ist bei Fehlern besser oder anderen Bussen, die es nicht am PC gibt (I2C, SPI, ...). Und natürlich bei > 2/4 Signalen parallel. Zum Protokoll: mit Multimeter Ruhepegel bestimmen. Mit LED die lange der Pakete, Polung und Pegel. Wenn es passt, am PC verschiedene baudrate ausprobieren. Oder was an Messtechnik da ist. Notfalls Oszi ausleihen. Oder an Soundkarte.
Espressif schrieb: > Geht das mit sowas: > ... <Link mit Lebensgeschichte> Der Link auf das Angebot reicht völlig. https://www.ebay.de/itm/334494398647
Espressif schrieb: > Gibt es dazu irgendwas wo man lesen kann wie man das mit dem Oszi macht? Man liest erst mal, was so ein UART prinzipiell macht, wie so ein UART-Telegramm aufgrebaut ist, was ein Start- und Stopbit ist, wozu ein mögliches Paritybit gut ist und in welcher Reihenfolge die Datenbits kommen. https://de.wikipedia.org/wiki/RS-232 https://de.wikipedia.org/wiki/Universal_Asynchronous_Receiver_Transmitter https://www.rohde-schwarz.com/de/produkte/messtechnik/oszilloskope/educational-content/uart-verstehen_254524.html usw, usf... Und dann misst man mal die Pegel dieses UART-Signals, ob es ein RS232-Pegel mit negativer Ruhespannung oder ein TTL-UART mit 5V/3V3 Ruhepegel ist. Und dann versucht man mal das, was man auf dem Oszibild sieht, mit dem, was man vorher gelesen hat, in Deckung zu bringen. > Also ich meine die Baud eines UART Signals analysieren? Man misst auf dem Oszi die Dauer vom Startbit bis zum Stopbit und teilt diese Zeit durch die Anzahl der Bits. Dann noch den Kehrwert davon und schon hat man die Baudrate. Wenn da was anderes herauskommt als die "üblichen" Baudraten, dann macht man diese Messung besser nochmal. A. S. schrieb: > Logikanalyzer ist bei Fehlern besser oder anderen Bussen Zuerst muss man wissen, welche Spannungen man auf dem Bus hat und wie das Bussigal aussieht. Und wenn man das weiß, dann kann man den LA für die Untersuchungen nehmen. Espressif schrieb: > Geht das mit sowas: > https://www.ebay.de/itm/334494398647 Wenn du schon was kaufst, dann kauf das billigste Picoscope, das hat schon mal 2 Kanäle. Und das Ding kann UART decodieren und auf der Festplatte speichern, bis die voll ist. Dieses EBAY-Ding liegt schon bald in der Ecke, das Picoscope ziehst du immer wieder raus...
:
Bearbeitet durch Moderator
Espressif schrieb: > Geht das mit sowas Fast. Nimm lieber ein DSO150, denn es hat ein ordentlich geschlossenes Gehäuse.
:
Bearbeitet durch User
Steve schrieb: > Nimm lieber ein DSO150 Meines stürzt aus beliebigen Gründen ab. Ich wünsche dem Programmierer viele Geräte mit ebenso schlechter Software... Wer das Ding also kauft, der muss im Grunde erst noch selber Hand anlegen: http://cvieth.bplaced.net/elektronik_dso150.html?_sm_au_=iJVtTJVjqSfnfzvgQFMGsK7JR7GKG
Lothar M. schrieb: > Nimm lieber ein DSO150 Wenn die open source software dafür stabil ist, wäre das aber ja super, dann kann ich mir auch gleich mal den Quellcode durchlsesn (Nicht dass ich ihn so wirklich verstehen würde) aber interessant ists trotzdem. Ich seh mich jetzt mal nach einem DSO150 um, und les mir das ganze über RS232 durch, ich will wissen wie dieser Akku kommuniziert, und wenns nur um das Herausfindens Willen ist.
Espressif schrieb: > ich will wissen wie dieser Akku kommuniziert Das wirst du mit dem kleinen Ding beim Analysieren nicht viel Freude haben. Espressif schrieb: > Er kommuniziert über UART mit dem Gerät, 9600 Baud Aber wenigstens siehst du dann, ob es überhaupt wie vermutet eine asynchrone Schnitte ist. Oder nicht eher ein synchroner Bus wie z.B. I²C...
Bedenkt man, daß das Gerät, das hier mit dem nichtssagenden Begriff "Handheld" beschrieben wird, ein PC ist, ist es eher unwahrscheinlich, daß die Kommunikation mit dem Akku über eine UART erfolgt -- wahrscheinlicher ist SMBus, der ist nämlich in PCs für so etwas da. Auch, wenn der PC in der Hand gehalten werden kann. Ansonsten bietet sich ein Oszilloskop nur für die Grobanalyse (Signalpegel und grobes Zeitverhalten) an, Details kann man (sofern die Spannungpegel passen) mit einem Logikanalysator wie den üblichen Saleae-Klonen deutlich besser und vor allem über einen längeren Zeitraum erfassen.
Lothar M. schrieb: > Aber wenigstens siehst du dann, ob es überhaupt wie vermutet eine > asynchrone Schnitte ist. Oder nicht eher ein synchroner Bus wie z.B. > I²C... Darum ging es mir bei der Empfehlung. Erstmal die Pegel und das Timing ermitteln, dann kann man passende Transceiver besorgen.
Habe das Gerät mal aufgemacht. Die Akku RX und TX hängen garnicht am Gerätemainboard selber, sondern an einem ESP32. Kann man darüber irgendwie rauskriegen wie das ganze kommuniziert?
Espressif schrieb: > Kann man darüber > irgendwie rauskriegen wie das ganze kommuniziert? Es bleibt bei der gleichen Vorgehensweise. Messe zumindest die Ruhepegel* dann kannst du (falls überhaupt nötig) passende Transceiver kaufen. Und den Logic Analyzer. *) Warum hast du das immer noch nicht gemacht? Willst du voran kommen, oder labern?
Stefan ⛄ F. schrieb: > Warum hast du das immer noch nicht gemacht? Willst du voran kommen, > oder labern? Noch kein Oszi vorhanden, bestelle jetzt das DSO150 dann wird Ruhepegel gemessen. Mal noch eine andere Frage: Kann man das ROM des ESP32 (Vorausgesetzt nicht gelockt) auslesen?
Espressif schrieb: > Noch kein Oszi vorhanden, bestelle jetzt das DSO150 dann wird Ruhepegel > gemessen. Für den Ruhepegel reicht ein simples Multimeter. Je nach dem, welche Spannung dabei heraus kommt kann man schon recht treffsicher erraten, welche Schnittstelle es ist. Ich vermute du wirst 3,0 bis 3,3V messen, dann ist es UART und du kannst den Logiktester direkt anschließen. Ich hoffe, du hast einen bestellt. > Mal noch eine andere Frage: Kann man das ROM des ESP32 (Vorausgesetzt > nicht gelockt) auslesen? Sicher kann man, mit dem esptool. Aber ich bezweifle, dass du binären Maschinencode verstehen kannst.
Stefan ⛄ F. schrieb: > Sicher kann man, mit dem esptool. Aber ich bezweifle, dass du binären > Maschinencode verstehen kannst. Das bezweifle ich auch, aber wenn ich einen zweiten ESP32 mit dem Programm aus dem von dem Gerät flashen könnte, wird der vielleicht den Akku auch entsperren.
Stefan ⛄ F. schrieb: > Für den Ruhepegel reicht ein simples Multimeter Habs grad gemessen. Ruhepegel ist 1,6v
Espressif schrieb: > Noch kein Oszi vorhanden, bestelle jetzt das DSO150 dann wird Ruhepegel > gemessen. Zum Messen des Ruhepegels brauchst du kein Oszi, solange die Schnittstelle in Ruhe ist. So ein DC-Signal misst jedes Multimeter. Ob auf deiner Schnittstelle geeignete Ruhepausen sind, weißt du ja bereits.
Espressif schrieb: > Habs grad gemessen. Ruhepegel ist 1,6v Bei einem ESP? Der arbeitet mit 3.3V Da hast du vermutlich eher einen Mittelwert über einen Datenstrom erwischt.
Wolfgang schrieb: > Espressif schrieb: >> Habs grad gemessen. Ruhepegel ist 1,6v > > Bei einem ESP? Der arbeitet mit 3.3V > Da hast du vermutlich eher einen Mittelwert über einen Datenstrom > erwischt. Hab den RX und TX vom Akku gegen GND gemessen als der Akku draußen war, daher hatten RX und TX keine Verbindung zum Gerät. Wenn der Akku mit dem Gerät verbunden wird, quatscht der die ganze Zeit, werd aber mal versuchen ihn wenn er verbunden ist in einer Pause zu erwischen, weiß nur nicht ob mir das gelingt, der fängt sobald er eingesetzt wird an zu quasseln
Wobei das Gerät erst den Akku anzusprechen scheint, also fängt das als erstes an zu quasseln, sobald er eingesetzt wird. Dann labert der Akku zurück, und das geht dann so die ganze Zeit ohne Unterbrechung sowohl von akku zu gerät als auch von Gerät zu Akku
Ich verwende diesen LA und bin sehr zufrieden damit. Bis 40 MHz mit großer Aufzeichnungstiefe. InnoMaker LA2016 USB Logik Analysator volle 16-Kanal 200MHz Abtastrate mit PC Software Handheld Instrument, Unterstützung Windows (32bit/64bit), Mac OS, Linux, (LA2016) https://amzn.eu/d/fboGxSa Unterstützte Standardprotokolle: UART/RS-232/485, I2C, SPI, CAN, DMX512, HDMI CEC, I2S/PCM, JTAG, LIN, Manchester, Modbus, 1-Wire, UNI/O, SDIO, SMBus, USB1.1, PS/2, NEC Infrarot, Parallel, etc.
Espressif schrieb: > Noch kein Oszi vorhanden, bestelle jetzt das DSO150 dann wird Ruhepegel > gemessen. Stefan ⛄ F. schrieb: > Für den Ruhepegel reicht ein simples Multimeter. Je nach dem, welche > Spannung dabei heraus kommt kann man schon recht treffsicher erraten, > welche Schnittstelle es ist. Ich vermute du wirst 3,0 bis 3,3V messen, > dann ist es UART und du kannst den Logiktester direkt anschließen. Ich > hoffe, du hast einen bestellt. Es ist völlig egal was der Typ bestellt, da der von Elektronik genausoviel Ahnung hat wie ich von einer Herztransplation - nämlich keine. Der hat sich jetzt nur in den Kopf gesetzt mal was mit Elektronik zu machen - macht doch jeder, kann nicht so schwer sein.
Stefan ⛄ F. schrieb: > Warum hast du das immer noch nicht gemacht? Willst du voran kommen, oder > labern Er will kaufen. Kaufen löst alle Probleme. Kaufen spart denken.
Espressif schrieb: > Habs grad gemessen. Ruhepegel ist 1,6v OK, das ist entweder kein UART oder er kommuniziert ununterbrochen (kein Ruhepegel). Dur brauchst wohl doch das Oszilloskop.
MaWin schrieb: > Du willst einfach nur kaufen. Kauf ein Eis. Hahaha!👍😂 UART, mach einen Stecker dazwischen und mit einem Terminalprogramm am PC gucken. Konnte früher fast jeder.
:
Bearbeitet durch User
Frank O. schrieb: > mach einen Stecker dazwischen und mit einem Terminalprogramm am PC > gucken. Espressif schrieb: > Soweit war ich schon
Bei Reichelt gibt es schon einfache Standoszilloskope ab 170€. https://www.reichelt.de/digital-speicher-oszilloskop-5-mhz-2-kanaele-peaktech-1400-p321522.html?&trstct=pol_4&nbc=1 Ok, nur 5 MHz. Aber für Uart und I2C reicht das vollkommen hin. Wenn man Spi langsamer taktet, evtl auch noch. 170€, das sind 2 Tankfüllungen. Oder 2 Helene Fischer Karten in Bremen. Oder eine Minitrix Elok, Spurweite N. Das kann man auch für ein Scope bezahlen. Jedes Hobby kostet. Und für den doppelten Preis gibt es schon 100 Mhz Geräte.
Mit Oszilloskops Protokollanalyse zu betreiben würe ich vorsichtig sein. Meist macht die geringe Speichertiefe die Analys sehr schwierig. Ich besitze beides und will einen LA nicht missen.
Gerald K. schrieb: > Mit Oszilloskops Protokollanalyse zu betreiben Darum geht es nicht, sondern darum, die Signalpegel und das Timing zu erkennen.
Stefan ⛄ F. schrieb: > Gerald K. schrieb: > >> Mit Oszilloskops Protokollanalyse zu betreiben > > Darum geht es nicht, sondern darum, die Signalpegel und das Timing zu > erkennen. Das können viele Oszis in der Grundausstattung, aber meistens kann man kurze Telegrammsequenzen speichern. Beim LA LA2016 lassen sich die Schaltschwellen einstellen und auch mehrere Schnittstellen gleichzeitig beobachten. Auch kommt man manchmal nicht mit zwei Kanäle aus. Z.B Handshakesignale, CS ... Wenn es um die Untersuchung von Störungen geht ist ein Oszi von Vorteil.
:
Bearbeitet durch User
Ich hab die RX und TX am Gerät weiter verfolgt. auf der Platine im Gerät mit dem ESP 32 sitzt auch ein ST3485EB, zu dem die RX und TX vom Akku gehen (Gemessen per Durchgangstest) also RS485, oder RS422, das Ding (ST3485EB) scheint nämlich nix anderes zu können. Das dürfte die Suche nach dem Protokoll eingrenzen.
Espressif schrieb im Beitrag #7176715: > Ich hab die RX und TX am Gerät weiter verfolgt. auf der Platine im > Gerät > mit dem ESP 32 sitzt auch ein ST3485EB, zu dem die RX und TX vom Akku > gehen (Gemessen per Durchgangstest) also RS485, oder RS422, das Ding > (ST3485EB) scheint nämlich nix anderes zu können. Das dürfte die Suche > nach dem Protokoll eingrenzen. Wenn du mit einem Scope einfach für 5 Sekunden die Messspitze an den Tx gehalten hättest, dann wüsstest du jetzt die Baudrate und das Spannungslevel. Das hätte hier jetzt 49 Posts gespart. Also besorg dir endlich vernünftige Laborhardware für Fakten, dann hört diese Spekuliererei endlich auf.
Gerald K. schrieb: > Beim LA LA2016 Guck mal, wieder was gelernt. Will im Winter wieder mit Elektronik anfangen und hab auch überlegt mir einen richtigen (hab so ein billig Ding) LA zu kaufen. Danke für den indirekten Tipp!
Espressif schrieb: > Ich hab die RX und TX am Gerät weiter verfolgt. auf der Platine im Gerät > mit dem ESP 32 sitzt auch ein ST3485EB, zu dem die RX und TX vom Akku > gehen Der ST3485EB besitzt am Ausgang kein RX und TX, sondern arbeitet mit den differentiellen Signalen A und B für einen bidirektionalen Bus. Kein Wunder, dass du Hausnummern misst.
Angehängte Dateien:
-
IMG_1127.jpg
170 KB
Frank O. schrieb: > Guck mal, wieder was gelernt. > Will im Winter wieder mit Elektronik anfangen und hab auch überlegt mir > einen richtigen (hab so ein billig Ding) LA zu kaufen. Diese Billigdinger sind so schlecht nicht! Ich hatte auch schon überlegt, mir ein Industriegerät zuzulegen (hp, Tektronix, DLI : ebay ab ~150€), aber A) brauche ich nicht 100-te von MS/sec, B) keine >= 64 Kanäle, C) nicht die flexibel konfigurierbaren Probes, D) sind Protokoll-Analyzer dafür oft nur als Option zu haben und E) braucht das alles richtig Platz auf dem Basteltisch. Für die Fälle, bei denen ich mit 5V-TTL nicht klar komme, frickle ich mir schnell was auf einem Lochraster-Rest zusammen (siehe Foto: Adaptierung auf z.B. 3.3V). Sollte mir mein Billigding mal abrauchen (was noch nie passiert ist), hol ich mir für 10€ ein Neues. Espressif schrieb: > Ich hab die RX und TX am Gerät weiter verfolgt. auf der Platine im Gerät > mit dem ESP 32 sitzt auch ein ST3485EB, zu dem die RX und TX vom Akku > gehen (Gemessen per Durchgangstest) also RS485, oder RS422, das Ding > (ST3485EB) scheint nämlich nix anderes zu können. Der TO könnte sich da analog z.B. einen ST3485 ran frickeln und mit dem an Pin 8 (Vcc) gemessenen Wert versorgen ... (Übrigens erübrigt sich damit die Messung des "Ruhepegels" - und Bitrate bekommt man per LA mit links raus ...) Wieso der TO einem 2-ten Faden aufgemacht hat - neben Beitrag "Kommunikation zwischen Akku und Gerät herausfinden", und nun hier dieselbe Soße ein weiteres mal aufgewärmt wird - das mag verstehen, wer's will ... Ich bin jedenfalls entgültig raus, lieber lerne ich meine Raufasertapete auswendig oder rede mit meiner Südwand!
Wolfgang schrieb: > Der ST3485EB besitzt am Ausgang kein RX und TX, sondern arbeitet mit den > differentiellen Signalen A und B für einen bidirektionalen Bus. > Kein Wunder, dass du Hausnummern misst. Und wie komme ich da jetzt weiter?
Dich interessieren die Signale an Pin 1 und Pin 4 des Treibers. Die haben Logikpegel (Versorgungsspannung des Treiberbausteins, zwischen Pin 8 und Pin 5 zu messen), d.h. Du kannst da direkt einen Logikanalysator der Art billiger Saleae-Klon anschließen und den seriellen Decoder in der Software verwenden. Pin 5 muss natürlich auch an den LA angeschlossen werden, das ist GND.
DANKE das ist mal richtig brauchbares Input. Sorry dass ich mich hier so blöde anstelle, aber das ist halt echt das erste mal dass ich mit dieser Art Kommunikation zu tun hab.
Espressif schrieb: > Und wie komme ich da jetzt weiter? Du könntest am Receiver Output RO und Driver Input DI des ST3485 messen. Dort sind die Pegel bekannt und die Signale der beiden Datenrichtungen liegen getrennt vor.
So habe mir jetzt mal einen LA5016 bestellt, werde damit mal an pin RO und DI des ST schnüffeln sobald der Analyzer kommt.
Wofür ist eigentlich der St3485 gut? Warum schließen die nicht den ESP32 direkt an die RX und TX zum Akku an?
Espressif schrieb: > Wofür ist eigentlich der St3485 gut? Das ist ein RS485-Treiber. > Warum schließen die nicht den ESP32 > direkt an die RX und TX zum Akku an? Weil der Akku keine RX und TX hat, sondern offensichtlich eine RS485-Schnittstelle.
DerEgon schrieb: > Dich interessieren die Signale an Pin 1 und Pin 4 des Treibers. > Die haben Logikpegel (Versorgungsspannung des Treiberbausteins, zwischen > Pin 8 und Pin 5 zu messen), d.h. Du kannst da direkt einen > Logikanalysator der Art billiger Saleae-Klon anschließen und den > seriellen Decoder in der Software verwenden. Pin 5 muss natürlich auch > an den LA angeschlossen werden, das ist GND. Ich würde versuchen den LA mit zwei Kanäle (1 UND 4) anzuschließen. Den GND des Gerätes mit dem GND des LA verbinden (LA2016 unterstützt ±5V). Damit bleibt die Symmetrie der seriellen Leitung erhalten. Man bekommt dann am LA zwei gegenphasige Signale angezeigt. Den LA mit GND an eine der beiden Signalleitungen anzschließen zerstört die Symmetrie total. Im schlimmsten Fall kommt es zum Kurzschluß.
Das verwirrt hier nur; ich beschrieb den Anschluss auf der *anderen Seite* des RS485-Treibers, dort, wo es ein eindeutiges RxD- und TxD-Signal gibt.
Also die Seite vom ST3485 zum Akku geht, und nicht die zwischen ESP32 zu ST3485? Die Frage ist, wenn ich es je hinkriegen sollte, rauszukriegen, wie diese Kommunikation funktioniert, kann ich dann mit einem normalen µC oder einem RS485 Adapter mit dem Akku reden, oder brauche ich dann den ESP32, plus ST3485 plus Hühnerfutter, plus wasauchimmer noch auf dem Board in dem Gerät sitzt auch? Wenn ich weiß die das kommuniziert, wäre die optimal solution natürlich eine kleine Platine, die einen µC enthält, mit der man den Akku dann wecken kann.
Espressif schrieb: > Also die Seite vom ST3485 zum Akku geht, und nicht die zwischen ESP32 zu > ST3485? Wer ist an den von mir genannten Pins 1 und 4 angeschlossen?
DerEgon schrieb: > Wer ist an den von mir genannten Pins 1 und 4 angeschlossen? Sobald ich wieder zuhause bin schau ich nach. Wie findet man eigentlich die Baudrate einer RS485 raus? Mitm Logic Analyzer oder Oszi?
Espressif schrieb: > Wofür ist eigentlich der St3485 gut? Warum schließen die nicht den ESP32 > direkt an die RX und TX zum Akku an? Sieh dir einfach mal in denren Datenblätter an, was die jeweiligen Pins aushalten. Und dann stell dir vor, da gibt es winters so eine hübsche kleine elektrostatische Entladung mit ein paar kV beim Akkuwechsel. Welcher der Pins hat da wohl mehr Chancen zu überleben? Espressif schrieb: > Die Frage ist, wenn ich es je hinkriegen sollte, rauszukriegen, wie > diese Kommunikation funktioniert Ist die Frage ernst gemeint? Und du willst eine ehrliche Antwort? Dann lautet die: so wie du derzeit ohne jeglichen Plan und Selbstantrieb herumdümpelst, wird das nie was. Espressif schrieb: > aber das ist halt echt das erste mal dass ich mit dieser Art > Kommunikation zu tun hab. Wenn dir das Ganze aber wirklich ernst ist, dann lass dir Zeit, wir anderen konnten das auch nicht von Geburt an. Wir mussten uns mit dem Thema auch erst mal ein wenig selber beschäftigen, uns dazu einlesen und ein paar Erfahrungen sammeln. Das hat dann schon mal eine Woche oder durchaus auch länger gedauert. Bis dein neuer LA also da ist, kannst du dich z.B. einfach mal zum Thema RS485 aufschlauen. EDIT: Espressif schrieb: > Wie findet man eigentlich die Baudrate einer RS485 raus? > Mitm Logic Analyzer oder Oszi? Hatte ich bereits geschrieben. Alternativ kannst du einfach mal selber anfangen über deine Aufgabe nachzudenken. Ich bin raus, das ist fast schon tragisch hier...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Bis dein neuer LA also da ist, kannst du dich z.B. einfach mal zum Thema > RS485 aufschlauen Da bin ich schon dran. Auch das DSO150 (Befürchte aber Clone) ist bestellt.
Espressif schrieb: > das DSO150 (Befürchte aber Clone) Gibt es das überhaupt in Original? Das ist ein chinesisches Produkt.
Stefan ⛄ F. schrieb: > Gibt es das überhaupt in Original? Das ist ein chinesisches Produkt. merkwürdige Frage. Die Chinesen können nichts selber entwerfen?
J. S. schrieb: >> Gibt es das überhaupt in Original? Das ist ein chinesisches Produkt. > merkwürdige Frage. Die Chinesen können nichts selber entwerfen? Soweit ich weiß gehören chinesische Entwicklungen der Volksrepublik. Jeder der eine Lizenzgebühr an die Behörden bezahlt darf das produzieren.
hmm, von einigen wie WeAct, Nextion, Waveshare habe ich aber schon gelesen das die vor counterfeits warnen. Kopien mit schlechter Qualität schaden ja schon dem Namensgeber, da wäre das sehr verwunderlich. Aber gelesen das es so oder nicht so ist habe ich es auch noch nicht.
Beim DSO150 ist beim Nachbau nicht nur die mangelnde (Noch mangelndere Qualität wie beim Original) das Problem. Denen ihre Firmware (Die "originale") hat die fiese Eigenschaft sich zu sperren wenn sie auf ein counterfeit Produkt gespielt wird, siehe hier: Beitrag "jyetech DSO150 Cortex Firmware decompile Fake Board" Man muss dann von der Platine des Gerätes einen Code lesen, und ihn an die Firma schicken, die dann einen Freischaltcode sendet, mit dem man das Gerät entsperren kann, DAS GEHT ABER NUR WENN DAS GERÄT ORIGINAL IST, sonst gibt von der Firma keinen Freischaltcode. Diese Sperre wurde anscheinend schon ausgehebelt, aber die zweite in der Originalfirmware anscheinend nicht: Solange die Firmware nicht freigeschaltet ist, lässt sich die Timebase nicht verstellen. Wobei ich auf meinem wahrscheinlich eh die Open Source Firmwaere installiere. Weis nur noch nicht, ob man das danach auch neu "kalibrieren" muss.
DerEgon schrieb: > Wer ist an den von mir genannten Pins 1 und 4 angeschlossen? Hallo. Habs nochmal nachgemessen. An Pin 1(RO) und Pin 4(DI) vom ST3485 hängt der ESP32.
Nun, dann häng' da Deinen LA ran, oder Dein Oszilloskop, und zeichne auf. Zeig einen Screenshot davon, dann kann man --vielleicht-- Dir beim Bestimmen der Baudrate weiterhelfen.
Ich hätte da bevor ich das Messen anfange noch eine kurze Frage: Ich habe hier: https://www.wut.de/e-6wwww-11-apde-000.php Folgendes gelesen Zitat: "Differenzmessungen (Messung Bus A gegen B), besonders mit einem Oszilloskop, können nur mit einem vom Massepotential galvanisch getrennten Messgerät durchgeführt werden. Viele Hersteller legen den Bezugspunkt des Messeinganges auf Masse, was bei Messungen an einem RS485-Bus zum Kurzschluss führen kann." Da das Handheldgerät und der Akku ja nicht am Netz hängen wenn ich dran rummesse (Das Oszi aber über den Netzadapter schon) sollte das ja aber kein Problem sein. Aber gegen was soll ich messen? Leitung - gegen +, andersrum, oder - und + einfach gegen GND? Ich weiß leider auch noch nicht welche der beiden Leitungen zwischen ESP32 und dem ST3485 RS485 + und welche - ist.
Espressif schrieb: > Aber gegen was soll ich messen? Leitung - gegen +, andersrum, oder - und > + > einfach gegen GND? Kanal_1 an +, Kanal_2 an -, GND an GND und im Scope dann Kanal_1 - Kanal_2 anzeigen.
Angehängte Dateien:
-
Pulseview.png
33 KB
Oh man, ist das eine schwere Geburt. Mit so einem Teil: Frank K. schrieb: > Diese billigen "24MHz 8Ch" Teile bei Amazon und anderen sind für übliche > UARTs bis 1MBit/s auf jeden Fall schnell genug. und Pulseview: - Datenblatt ST3485EB anschauen, mit Resultat: DerEgon schrieb: > Dich interessieren die Signale an Pin 1 und Pin 4 des Treibers. - Drei Kabel zum Logicanalyzer verbinden (1+4 und GND an Pin5) - Pulseview einige Zeit aufzeichnen lassen - "Guess Bitrate"-Decodermodul reinklicken - Baudrate ablesen - UART-Decoder-Modul reinklicken, Baudrate aus vorhergehendem Schritt einstellen. - ggfs. Andere Einstellungen vom UART-Decoder durchspielen (Parity, Stop-Bits, Invert RX/TX...), bis keine Framing-Errors mehr angezeigt werden. - ... - Profit. - Bonus: Evtl. passt noch ein anderer Decoder dazu, der sich hinter den UART-Decoder "stacken" lässt. Im Screenshot: Komplett sinnfreie Demo-Daten, und ein "UART->Modbus Decoder", was auch keinen Sinn macht.
Habe das ganze jetzt mal mit dem LA5016 gelesen. GND auf GND vom ST, Kanal 0 auf Pin 1 vom ST, Kanal 1 auf Pin 4 vom St. Auf Kanal 0 gibt es bei einer Baudrate von 115207 sporadisch framing errors, auf Kanal 1 (Der an Pin 4 vom ST hängt) gibt es bei dieser Baudrate keinerlei framing errors. Ich könnte jetzt versuchen, das mit dem LA gelesene einfach mal per RS485 Adapter an die Batterie zu senden, und sehen ob sie sich davon beeindrucken lässt. Aber wie mache ich das? Der LA wirft werte wie 0x62, 0x65, 0x74 raus. Wie sende ich die in Hterm über einen RS485 Adapter an die Batterie?
:
Bearbeitet durch User
Angehängte Dateien:
-
HTermTx.jpg
50 KB
schrieb: > Aber wie mache ich das? Der LA wirft werte wie 0x62, > 0x65, 0x74 raus. Wie sende ich die in Hterm über einen RS485 Adapter an > die Batterie? Im HEX Modus ohne <CR><LF> am Ende.
schrieb: > Ich könnte jetzt versuchen, das mit dem LA gelesene einfach mal per > RS485 Adapter an die Batterie zu senden, und sehen ob sie sich davon > beeindrucken lässt. Aber wie mache ich das? Der LA wirft werte wie 0x62, > 0x65, 0x74 raus. Wie sende ich die in Hterm über einen RS485 Adapter an > die Batterie? Keine Ahnung von nichts >> lass es sein oder mache Dich schlau. Kleiner Tip: Lesen bildet. Wer sich alles nur vorkauen lässt lernt halt nichts. Du demonstrierst da gerade recht eindrucksvoll.
Gerald K. schrieb: > Im HEX Modus ohne am Ende. Im HEX Modus ohne **CR** **LF** am Ende Anmerkung zu meiner Korrektur: spitze Klammerung um CR LF funktioniert nicht!
:
Bearbeitet durch User
Zeno schrieb: > Keine Ahnung von nichts >> lass es sein oder mache Dich schlau. Kleiner > Tip: Lesen bildet. Wer sich alles nur vorkauen lässt lernt halt nichts. > Du demonstrierst da gerade recht eindrucksvoll. Dann sag mir halt WO LESEN? Wenn ich QUellen fpür sowas finden würde, würde ich ja lesen. Ich würde auch gerne Kapieren warum das mit dem LA gelesene auf dem einen Kanal sinn ergibt, und auf dem anderen mit den selben Einstellung nix als framing errors gibt. Also WO lesen? sagt mir helt wenigestens wo.
Zeig doch mal einen Screenshot von dem, was Dein Logikanalysator da ausspuckt.
schrieb: > Ich würde auch gerne Kapieren warum das ... > auf dem anderen mit den selben Einstellung nix als framing errors gibt. (Es geht um Pin 4, dem Logic-Level Input des RS485 Treibers.) Weil die Signale halt nicht den UART Protokoll überein stimmt. Oder du hast die falsche Baudrate eingestellt. 115207 ist ungewöhnlich, die nächste normale Baudrate ist 115200. Aber ich denke, der feine Unterschied wird wohl nichts an deinen Framing Errors ändern. Wenn du uns so ein Bild zeigen würdest, wie der Ernst B es vor gemacht, könnten wir mehr dazu sagen. Normalerweise kann man die Signale auch in eine Datei aufzeichnen und hier an Anhang bereit stellen. Wenn das alles Klappt bekommst du eine Folge von Bytes, deren Sinn du genau so wenig verstehst, wie eine fremde Sprache. Was willst du ohne "Wörterbuch" damit anfangen?
MaWin schrieb: > Du willst einfach nur kaufen. Kauf ein Eis. Es ist ein Trauerspiel... Nun hat der TO gekauft - und die ganzen Spezialisten, die vorher lautstark bestimmte Chinakracher empfohlen haben (nach dem Motto: Hab' ich auch zuhause, muss also einfach gut sein), haben sich in ihren Löchern verkrochen...
Jester schrieb: > Es ist ein Trauerspiel... > Nun hat der TO gekauft Er hat bekommen, was er wollte. Er wollte die Kommunikation auf dieser Schnittstelle analysieren. So weit ist er nun. Dass er mit dem Ergebnis der Analyse wahrscheinlich auf die Schnelle nicht anfangen kann, war zu erwarten. Nur sehr wenige Geräte kommunizieren mit Klartext auf deutsch oder englisch. Klar gibt es hier Experten, die ihm weiter helfen könnten, wenn er seine Geräte nun dazu benutzen würde, den nötigten Input zu liefern. Nur wenn das in der Qualität weiter geht, wie bisher, dann stirbt er vorher an Altersschwäche. Dafür können jedoch die Experten nichts. Ich hätte als nicht-Experte schon vor dem Messen den Akku zerlegt und ermittelt, welcher Chip da drin ist. Dann nach dessen Dokumentation gesucht. Wenn ich da nicht heran gekommen wäre, hätte ich das Projekt abgebrochen. Digitale Kommunikation ohne Doku zu hacken ist nämlich, wie das Entschlüsselung einer Fremdsprache ohne Wörterbuch. Das artet schnell zu einem Lebenswerk aus.
Angehängte Dateien:
-
Akku_BMS_UART_Analyse.JPG
100 KB -
Batterie_UART_Einstellungen.JPG
32 KB
Wer misst ... schrieb: > Zeig doch mal einen Screenshot von dem, was Dein Logikanalysator da > ausspuckt. Hier mal alles was ich so habe, die Project file muss man mit dem KingView Programm öffnen, der LA5016 funktioniert nicht mit Pulseview
schrieb: > Akku_BMS_UART_Analyse.JPG Bitte Channel 1 so darstellen, dass man das Timing der High/Low Phasen ablesen kann. > King_View.zip Ohne die exportierten Rohdaten der Messung kann ich mit dem Programm nichts anfangen. Siehe http://www.inno-maker.com/wp-content/uploads/2019/02/Kingst_Virtual_Instruments_User_Guide.pdf Seite 23. Darfst du die Software einfach hier veröffentlichen? Ich weiß, ich mache das mit einigen Programmen auch auf meiner Homepage, aber da habe ich vorher um Erlaubnis gefragt.
Angehängte Dateien:
-
Timing.JPG
98 KB
Ich denke man darf das Programm hier hochladen, das ist ja ohne den LA so gut wie nutzlos und nur als Reader zu gebrauchen. Außerdem kann man das eh soweit ich weiß auf der Herstellerseite downloaden. Hier mal die Rohdaten und ein Screenshot mit dem Timing.
Das hab ich selber schon rausgefunden, aber auf Kanal 0 gibt es framing errors, auf Kanal 1 nicht. Ich frag mich warum
Ich hab da mal weiter probiert. Ich weiß zwar noch nicht warum die framing errors auf Kanal 0 passieren, aber die Kommunikation auf Kanal 1 (An Pin 4 des ST) ist bei jedem Einsetzen des Akkus die gleiche, daher denke ich nicht, dass es ein verschlüsseltes System, oa ist, sonst wären die Daten doch jedes mal anders?
Beitrag #7181572 wurde vom Autor gelöscht.
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.