Hallo zusammen, ich bin neu hier, daher verzeiht bitte wenn ich die Regeln hier noch nicht ganz beherrsche. Ich suche für folgendes Problem eine Lösung: Ich habe einen RFID Leser, welcher seine Daten via rs232 an einen RPi überträgt. Das funktioniert auch wunderbar. Die Parameter des RFID Lesers können, über eine Windows Konfigurationssoftware und USB/RS232 Adapter, geändert werden. Auch das funktioniert. Leider gibt es diese Software nicht für Linux, außerdem möchte ich verschiedene Parameter direkt, ohne diese Software, verändern. Ich denke, dass müsste über entsprechende Befehle an /dev/serial0 (der Link zum COM-Port) funktionieren. Meine Idee war, die Kommunikation der rs232 Schnittstelle am Windows PC während der Einstellung eines Parameters über das Windows Programm zu protokollieren oder über od unter Linux auszulesen. Da bekomme ich auch verschiedenste Werte. Beispiel: Ich schalte über das o.g. Programm den Buzzer aus, welcher nach dem einlesen einer Karte kurz piept. Unter Linux erhalte ich via od dann folgende Ausgabe: od -x < /dev/ttyS0 0000000 4652 0001 4100 0300 0107 1b00 4652 0001 Ich habe aber keine Ahnung was ich denn nun mit diesen Werten machen soll und wie ich die an den Leser übertrage. Ich habe hier im Forum etwas in der Richtung gelesen, dass man ein yxz.bin File an die Schnittstelle senden soll. Nur wie erstelle ich dieses bin File? Es gibt auch ein SDK für Windows (C#) für den Leser, damit kann ich persönlich aber nichts anfangen, da ich es nicht verstehe. Hat jemand von euch eine Idee, wie ich da vorgehen könnte? Vielen Dank schon einmal. VG Volker
Volker schrieb: > Es gibt auch ein SDK für Windows (C#) für den Leser, damit kann ich > persönlich aber nichts anfangen, da ich es nicht verstehe. > > Hat jemand von euch eine Idee, wie ich da vorgehen könnte? Du könntest es mal mit Lernen versuchen. Nach unbestätigten Gerüchten soll das manchmal hilfreich sein...
c-hater schrieb: > Du könntest es mal mit Lernen versuchen. Nach unbestätigten Gerüchten > soll das manchmal hilfreich sein... Versuch Du es mal mit Höflichkeit.
BlaBla schrieb: > Versuch Du es mal mit Höflichkeit. Beim C-Hater ist das mit dem Lernen scheinbar auch schwierig... ob er jemals noch lernt höflich zu sein? Volker schrieb: > Es gibt auch ein SDK für Windows (C#) für den Leser, damit kann ich > persönlich aber nichts anfangen, Du musst nicht C# vollständig in allen Details verstanden haben, um aus dem SDK (so es denn im Source vorliegt), die Stellen rauszusuchen die die Kommunikation mit dem Reader vornehmen. Halte ich für einfacher, als Volker schrieb: > Meine Idee war, die Kommunikation der rs232 Schnittstelle am Windows PC > während der Einstellung eines Parameters über das Windows Programm zu > protokollieren oder über od unter Linux auszulesen. Vor allem, wenn die Kommunikation bi-direktional mit mehreren Befehl-Antwort-PingPongs läuft ==> Beide Richtungen mitlesen, ein einfacher (5€)-LogicAnalyzer könnte das vereinfachen. Ansonsten: C# Läuft auch unter Linux (Mono), zumindest die Nicht-GUI-Sachen recht problemlos. Insofern läuft das SDK evtl. auch auf deinem RasPi. Womit wir aber wieder beim Vorschlag vom C#-Hater sind: Du wirst dich mit C# auseinandersetzen müssen.
Mit Deinem Wissen dürfte Dein Vorhaben recht schwierig umzusetzen sein. Volker schrieb: > od -x < /dev/ttyS0 > 0000000 4652 0001 4100 0300 0107 1b00 4652 0001 Das was Du hier zeigst ist eine einfache Folge von Bytes, die hier übertragen werden. Ich kenne jetzt das Programm od nicht aber die ersten 7Byte (0000000) sind ein Zähler (hexadezimal) für die Anzahl der vorangehenden Nibble. Eine 2. Zeile des Dumps würde daher mit 0000020 (dezimal=32) beginnen, weil in DEiner Zeile 8 Worte = 16 Byte = 32 Nibble übertragen wurden. Interessant für den übertragenen Befehl ist also alles was nach 0000000 kommt. Allerdings wird Dich meine Erklärung auch nicht weiter bringen, weil Dir das Verständnis bzw. die Grundlagen hierfür fehlen. Deshalb hat der c-hater hier recht, wenn er sagt setze Dich auf den Hosenboden und lerne die Basics, wie Bit, Nibble, Byte Wort, serielle Kommunikation etc. etc.. Es gibt genug Fachbücher als auch Onlinetutorials wo so etwas haarklein beschrieben wird, nur Lernen mußt Du selbst tun.
BlaBla schrieb: > c-hater schrieb: >> Du könntest es mal mit Lernen versuchen. Nach unbestätigten Gerüchten >> soll das manchmal hilfreich sein... > > Versuch Du es mal mit Höflichkeit. Für c-hater ist das doch ausgesprochen höflich und er hat Recht, der TO sollte sich auf den Hosenboden setzen und die Basics lernen. der ist jetzt schon eine Aufforderung zum eigenständigen Lernen zuviel verlangt? - ich denke nicht.
Zeno schrieb: > der ist jetzt schon eine Aufforderung zum eigenständigen Lernen zuviel > verlangt? Das war ja noch nicht mal eine Aufforderung, sondern eindeutig als Vorschlag formuliert. Ich wüßte nicht, wie man das noch höflicher formulieren sollte. Manche Spinner sehen halt Unhöflichkeit überall dort, wo ihnen die Sache selber schlicht nicht paßt.
c-hater schrieb: > Nach unbestätigten Gerüchten soll das manchmal hilfreich sein... Keine Weihnachtsgeschenke bekommen ? Kein Wunder, ätzende Hater wie du bekommen auch nix. Volker schrieb: > Ich habe aber keine Ahnung was ich denn nun mit diesen Werten machen > soll Erst mal keinen 16 bit dump, sondern 8 bit. Dann die Datei direkt an den RFID Reader senden und gucken, ob auch das zum Umstellen des Buzzers führt. Mit Gluck bekommst du so eine Sammlung von Dateien für alle Konfigurationen. Schwieriger wird es, wenn die Konfiguration Zahlen als Parameter enthält und gar noch eine Prüfsumme. Da will man kaum für jeden Zahlenwert eine Datei vorhalten, sondern lieber das Konstruktionsprinzip herausfinden. Noch schwieriger wird es, wenn die Datei nach challenge response jedesmal anderen Inhalt hat.
Michael B. schrieb: > c-hater schrieb: >> Nach unbestätigten Gerüchten soll das manchmal hilfreich sein... > > Keine Weihnachtsgeschenke bekommen ? > Kein Wunder, ätzende Hater wie du bekommen auch nix. Also in diesen Worten von hater sehe ich nun wirklich keine Unhöflichkeit. Da warst Du nach meinem Verständnis jetzt unhöflicher. Aber sei's drum , ist halt Ansichtskarte. Michael B. schrieb: > Erst mal keinen 16 bit dump, sondern 8 bit. Diese Formatierung scheint das Programm aber so vorzugeben. Man kann zwar zwischen verschiedenen Ausgabeformaten wählen, aber die sind noch unübersichtlicher. Mit der Option "Ausgabe als Text" bekäme man zwar eine Ausgabe als 16 Chars, also 16Byte, das dürfte den TO aber auch nicht weiter bringen, da ihm schlichtweg die Grundlagen fehlen. Michael B. schrieb: > Schwieriger wird es, wenn die Konfiguration Zahlen als Parameter enthält > und gar noch eine Prüfsumme. Da will man kaum für jeden Zahlenwert eine > Datei vorhalten, sondern lieber das Konstruktionsprinzip herausfinden. > > Noch schwieriger wird es, wenn die Datei nach challenge response > jedesmal anderen Inhalt hat. Ja und da sind wir wieder da, was hier schon der Grundtenor war: Der TO wird sich auf den Hosenboden setzen müssen und lernen. Die gebratenen Tauben die noch dazu von alleine in den Mund fliegen sind leider aus.
von Volker schrieb: >Ich habe hier im Forum etwas in der Richtung gelesen, dass man ein >yxz.bin File an die Schnittstelle senden soll. Nur wie erstelle ich >dieses bin File? Mit folgender Befehlszeile kannst du Binärdaten in Textform in eine echte Binärdatei umwandeln. xxd -r test.bin.txt > test.bin Und dann prüfen ob es geklappt hat, mit: xxd -u -g1 test.bin
Moin, den kleinen LogicAnalyzer(LA) würde auch ich empfehlen. Der macht vieles einfacher und man lernt automatisch neues. Toll das der Volker das mit dem Linux Sniffer schon hinbekommen hat. Ich würde das mitgelesene gesendete erst mal versuchen mit eigener Software zu senden. Dann kannst du es manipulieren und sehen was passiert. Dauert halt ein bischen und ist frickelig aber geht. Sollte dir aber auch ab einem gewissem Punkt Spass machen. Da hilft der LA dabei.
Immerhin hat der TO von 100 % schon fast 50 % richtig gemacht.
Was ja fuer einen Anfaenger eine gute Quote ist.
Statt eines od haette sich eben eher ein hd angeboten.
Das ist leider in vielen "Linuxen" nicht dabei.
Aus einem LA-Log muesste man die Werte womoeglich erst abtippen.
Und das wiederum in C zu senden ist auch Anfaengern kein Problem:
printf("%c%c%c%c",0xde,0xad,0xbe,0xef);
Gegebenenfalls muss man aber zwischen Befehlen dem Reader
Zeit geben um das Kommando auch zu verarbeiten.
Das koennen durchaus auch mal mehrere 100 ms sein.
Da kann es dann schon sinnvoll sein, mit einem LA die
Initialisierung mutzuschneiden, und diese Zeiten zu notieren.
Hallo, vielen Dank für die Tipps. Da habe ich ja einige interessante Ansätze und ich hatte schon immer Spaß an Frickeleien ;-) Der LA ist im Zulauf. Für die "sozial engagierten Erzieher" hier, ganz kurz zu mir: Ich bin Dipl. Ing. im Maschinenbau, habe auch nach mehr als 35 Berufsjahren in 6 Ländern ganz bestimmt kein Problem damit neues zu lernen und vermutlich schon mehr vergessen als so mancher je lernen wird. Aber niemand kann je alles Wissen und daher nochmals danke an alle sachlichen Hinweisgeber, denen ich nicht zu dumm oder faul erschien. VG Volker
Volker schrieb: > Es gibt auch ein SDK für Windows (C#) für den Leser Hast du uns einen Link zu dem SDK? Oder genaue Bezeichnung von dem Leser?
Hallo Adam, das ich ein ACM812A von Goldbridge. Alles weitere habe ich Dir, aus vertragsrechtlichen Gründen, als PN geschickt. VG Volker
Ein ueberaus nuetzliches Instrument fuer RFID-Installationen ist auch eine Impedanzmessbruecke. Ohne steht man sonst im Dunklen. Die sollte bis mindestens 30 MHz funktionieren und das Stehwellenverhaeltnis bezogen auf 50 Ohm anzeigen koennen. Die sind nicht gaaanz so billig wie ein China LA. Ich hatte mir damals den Palstar ZM-30 ausgeguckt und der tat was er sollte. Ich hatte "gluecklicherweise" gleich ein paar MMICs ERA-3 besorgt. Die gingen bei dem naemlich gerne mal kaputt.
Hallo zusammen, ich habe inzwischen mein Ziel erreicht, wenn auch nicht sauber mittels Programmierung aber über den ursprünglichen Ansatz die gesnifften Daten zurück zu senden. Ich führe das mal aus, falls mal jemand ein ähnliches Problem hat. Der LA ist toll, brachte mich wenig weiter, da dieser nicht die Werte der tatsächlich gesendeten Daten ausgab. Das kann aber auch eine Einstellungsthema in der LA Software sein, mit welchem ich mich im Nachgang interessehalber beschäftigen werde. Die Analyse des C# Codes half auch nur bedingt weiter, weil dieser nur Werte an Funktionen aus einer eingebundenen C++ DLL weitergibt. Die C++ DLL konnte ich nicht weiter analysieren. In Github fand ich eine ganze Reihe von Projekten welche RFID Reader konfigurieren, bis auf eines binden aber alle diese eine DLL mit ein. Zumindest weiß ich jetzt etwas mehr über C#. Tatsächlich behalf ich mich dann mit dem Ausspähen der vom mitgelieferten Windows Programm gesendeten Codes mittels dem "Advanced Serial Port Monitor" von AGG Software, welcher auch über einen Spy Mode verfügt und die serielle Schnittstelle nicht blockiert. Die so ermittelten Hex Werte, z.B. 52 46 00 00 00 10 00 00 58 kann ich nun unter Linux mit einem einfachen echo an die serielle Schnittstelle senden echo -e "\x52\x46\x00\x00\x00\x10\x00\x00\x58" > /dev/serial0 . Theoretisch ergibt das nun, wie auch hier von euch beschrieben, eine Liste von Hex-Befehlszeilen. Die Hexwerte bauen aber nummerisch auf einander auf, so dass ich recht schnell in der Lage war, den entsprechenden Funktionswert und das Byte in der Befehlsfolge festzulegen. Die gesendeten Werte fand ich hingegen im SDK (in Software wie auch in der Dokumentation) so nicht wieder, was aber eine andere Geschichte ist. Mein Problem ist jedenfalls gelöst. Vielen Dank an alle, die mir hier mit konstruktiven Vorschlägen geholfen haben. VG Volker
Sowohl die Salea Soft als auch Open Source Pulseview unterstützen div.Protokolle. Finde heraus welches bei dir verwendet wird. Dann bekommst Du, falls von der LA Soft unterstützt, Klartext Info angezeigt. Probiere es aus, lohnt sich.
1.) Mit Wireshark + Rs232Converter die Kommunikation sniffen und die Datei.txt speichern 2.) .bin (auf Windows Konfiguratiostool.exe) ist das Konfigurationswerkzeug-Programm (was du programmieren musst) die dann auf dein RPi (unter Linux) laufen muss. Welche Programmiersprache verwendest du? Kommunikationsprotokoll :(
Das Wichtigste ist das Kommunikationsprotokol. Wenn das nicht bekannt ist, kommt eine unvorhersehbare Komponente rein. zB wenn man nicht einfach aufgezeichnete Muster wiederholen kann. Einen unbekannten CRC/Checksumme kann man zB aufzeichenen indem man alle Moeglichkeiten durchprobiert. ein 16 bit CRC/Checksumme hat nur 65536 Moeglichkeiten, die kann man durchprobieren, bis eine Antwort kommt. Dumm waere wenn dadurch tatsaechlich eine aktion ausgeloest wuerde.
:
Bearbeitet durch User
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.