Hallo zusammen, seit kurzem bin ich Besitzer von einem Opel Astra, dieser ist mit Reifendrucksensoren ausgestattet. Jeder Sensor hat eine ID, misst den Überdruck im Reifen und sendet diesen dann via Funk (433,92 MHz) zum Seuergerät. Diese Reifendrucksensoren sind laut Anleitung verbaut: Schrader Electronics Ltd. 11 Technology Park, Belfast Road, Antrim BT41 1QS, Northern Ireland, United Kingdom Betriebsfrequenz: 433,92 MHz Maximalleistung: 10 dBm Diese Sensoren, also die Sensor-ID, muss an das Steuergerät angelernt werden. Dazu kann man dieses Gerät (EL-50448 bzw. OEC-T5) verwenden : http://www.orange-electronic.com/eu/download/manual/bedienungsanleitung_el_50448.pdf Ich habe das gleiche Problem (Gerät funktionier scheinbar nicht) wie Jürgen aus diesem Beitrag: https://www.motor-talk.de/forum/fragen-und-problem-reifenanlerngeraet-el-50448-t5628248.html Allerdings habe ich etwas bessere Fotos von diesem Gerät gemacht ;-). Soweit ich alle Bauteile erkennen konnte, sind es: 1x LM358 (zweifacher OPV) 2x HEF4060BT (14-stufiger Asynchron-Binärzähler / Teiler und Oszillator) Widerstände, Kondensatoren, eine Diode, ein Quarz, die Antenne ist eine Spule mit Ferritkern welche an die äußeren Pins der Steckbuchse angeschlossen wird. Was ist denn das Bauelement U201 (links unter der Steckbuchse)? Dies müsste ja der Mikrocontroller sein oder? Kennt jemand den Typ? Die Schaltung funktioniert nicht, LED leuchten nicht. Messungen konnte ich noch nicht durchführen da ich hier kein Multimeter habe. Betrieben wird die Schaltung von einem 9V-Block. Vielleicht kann noch jemand etwas zur Funktion sagen?
:
Verschoben durch Moderator
Opelfahrer schrieb: > Dies müsste ja der Mikrocontroller sein oder? Wäre das ein Mikrocontroller, wäre der Rest der Schaltung überflüssig, denn so ein MC kann Zähler komplett ersetzen, es wäre nur noch ein Verstärker zur Antenne nötig. Und soweit ich sehe, ist der TI Chip genau das. Hier findet sich aber sicher jemand, der mit 37322 83M von TI was anfangen kann.
Matthias S. schrieb: > Hier findet sich aber sicher jemand, der mit > > 37322 > 83M > > von TI was anfangen kann. Vielleicht einfach mal nach: texas 37322 SO8 suchen
Sind Pin 6 und 7 verbunden? Vielleicht der, der die Ferrit Spule treibt? http://www.ti.com/lit/ds/symlink/ucc37322.pdf Wie z.B. die beiden unten rechts: https://ic.pics.livejournal.com/hovvardhughes/66130694/21617/21617_original.jpg
Hallo, Opelfahrer schrieb: > Was ist denn das Bauelement U201 (links unter der Steckbuchse)? > Dies müsste ja der Mikrocontroller sein oder? > Kennt jemand den Typ? Könnte der UCC37322 Low-side driver sein. "9-A/9-A single-channel gate driver with split outputs, 25-ns prop delay, and enable" http://www.ti.com/product/UCC37322?keyMatch=UCC37322D Mit freundlichen Grüßen Guido
Hallo, Versuch schrieb: > Vielleicht einfach mal nach: > texas 37322 SO8 > suchen ...oder nach "texas instruments marking 37322". Meine Erfahrung ist, dass der Gehäusetyp bei der Suche meist weniger relvant ist. "marking" ist als Schlüsselwort jedoch oft hilfreich. Mit freundlichen Grüßen Guido
pegel schrieb: > Sind Pin 6 und 7 verbunden? Es sieht erstmal micht so aus, vielleicht unter dem Gehäuse. Es wir aber nur der Eingang B verwendet. Die rote LED soll "LOW BAT" anzeigen und die grüne "TX" für transmitt. Das weiße runde ist ein Taster. Hier das Gerät in Funktion: https://www.youtube.com/watch?v=HIdYpSt_Id8
Ihr habt recht das Bauteil sollte dieses hier sein: http://www.ti.com/lit/ds/symlink/ucc37322.pdf also ein "UCC2732x/UCC3732xSingle9-A High-Speed Low-Side Mosfet Driver With Enable" sein. Vielleicht liegt es am R214 oder R211 der ist ja nicht bestückt. Unter dem großen Kondensator sind dauch noch zwei Widerstände wo nur einer der beiden bestückt ist.
Opelfahrer schrieb: > Die Schaltung funktioniert nicht, LED leuchten nicht. Messungen konnte > ich noch nicht durchführen da ich hier kein Multimeter habe. Warum reklamierst Du das Teil nicht? Deshalb? https://de.aliexpress.com/item/4000656410167.html Die "Autodoktoren" sagen dazu: Wer billig kauft, kauft öfter :-) (oder so ähnlich ...)
:
Bearbeitet durch User
Hugo H. schrieb: > Warum reklamierst Du das Teil nicht? Das werde ich wohl machen, ich hatte nur gedacht vielleicht bekommt man das Ding doch in Gang ohne das ganze drumherum einer Reklamation. Da das ja schon der zweite Anlauf war (die erste Bestellung hatte ich an einen Packstation liefern lassen, aber ich wusste nicht das man dazu auch eine DHL-Karte braucht, ich dachte eine Postnummer reicht. Somit ging das erste Paket gleich zurück, wahrscheinlich wurde es dann vernichtet und mir wurde der Kaufpreis erstattet. Das war mein Fehler ich bestelle ungern bei den Amazonen.)wollte ich nicht nochmal das Theater. Das ganze Thema dauert jetzt schon 4 Wochen. Dieses Gerät (nicht die Schaltung) ist ja so sinnlos, sowas gehört ins Auto eingebaut und fertig. Ökodesignrichtlinie nicht beachtet, aber es sind ja viele Beteiligte die damit ein Geschäft machen. Denn ohne diese Druckanzeigt hat man wohl beine Betriebsgenehmigung/TÜV mehr. Gut jetzt sonst wird der Beitrag noch zu Politik gezählt und fliegt raus. Ich werde den Versender morgen mal anrufen mal sehen was dann kommt.
Hugo H. schrieb: > Deshalb? Naja so günstig habe ich es nicht bekommen, es waren so um die 10 Euro. Und das finde ich angemessen für die kleine Schaltung, die Bauteile sind ja jetzt nicht von No-Name Herstellern, gelötet ist es auch ordentlich. Das gleiche Gerät gibt es auch für 20, 30, 70 oder 150 Euro. Da ist wahrscheinlich auch nichts anderes drin verbaut.
Bei TI muss man nicht raten, da lässt man nachschauen: http://www.ti.com/packaging/docs/partlookup.tsp? Arno
Opelfahrer schrieb: > Das gleiche Gerät gibt es auch für 20, 30, 70 oder 150 Euro. Da ist > wahrscheinlich auch nichts anderes drin verbaut Möglicherweise. Warum nur will das von Dir gekaufte Gerät nicht funktionieren? Opelfahrer schrieb: > Ich werde den Versender morgen mal anrufen mal sehen was dann kommt Kannst Du Dich in chinesischer Sprache verständigen?
:
Bearbeitet durch User
Was passiert denn, wenn man das Knöpfchen drückt? Lt. Video soll ja dann die grüne LED hektisch blinken für ein paar Sekunden.
Beitrag #6223823 wurde von einem Moderator gelöscht.
Beitrag #6223844 wurde von einem Moderator gelöscht.
Beitrag #6224084 wurde von einem Moderator gelöscht.
Hugo H. schrieb: > Möglicherweise. Warum nur will das von Dir gekaufte Gerät nicht > funktionieren? > Das weis ich auch (noch) nicht, wenn ich es weis schreib ich es hier rein. > > Kannst Du Dich in chinesischer Sprache verständigen? Laut Versender war der Standort vom Artikel Frankfurt an der Oder. Dort sollte auch deutsch gesprochen werden. Mal sehen was für eine Antwort kommt. 9093 positive zu 119 negativen Bewertungen, 154 neutral. Ein deutsches Gerät "Made in Germany" habe ich leider nicht finden können. Vielleicht kennst Du ja eins?
Matthias S. schrieb: > Was passiert denn, wenn man das Knöpfchen drückt? Lt. Video soll ja dann > die grüne LED hektisch blinken für ein paar Sekunden. Leider passiert nichts, auch die Low Bat Anzeige leuchtet nicht, ich hatte mal ein einstellbares Netzgerät angeschlossen und dann die Spannung von 9V auf 1,5V abgesenkt.
Opelfahrer schrieb: > Laut Versender war der Standort vom Artikel Frankfurt an der Oder. > Dort sollte auch deutsch gesprochen werden. Je nach Ohr des Betrachters, vielleicht mit deutlich östlichem Akzent. Ob Du wirklich telefonieren willst, ist Deine Entscheidung: Das Telefonat samt Versprechungen kannst Du nicht belegen, also besser über das Reklamationssystem der Handelsplattform mailen. > Ein deutsches Gerät "Made in Germany" habe ich leider nicht finden > können. Vielleicht kennst Du ja eins? Die Suche wird erfolglos bleiben, Du wirst bestenfalls einen deutschen Anbieter finden, der seinen Namen auf ein Chinaprodukt kleben lässt und dafür den dreifachen Preis verlangt. Die Gier nach Gewinn bringt die Elektronikfertigung im eigenen Lande gegen Null - leider. Opelfahrer schrieb: > Leider passiert nichts, auch die Low Bat Anzeige leuchtet nicht, ich > hatte mal ein einstellbares Netzgerät angeschlossen und dann die > Spannung von 9V auf 1,5V abgesenkt. Es ist zwar ärgerlich, aber wohl ein eindeutiger Fall für Gewährleistung.
So ganz nebenbei: Wie funktioniert das Ganze überhaubt? Also, wie wird die Elektronik im Rad stimuliert, um sich am FZ zu melden? Kann man das nicht einfach selber bauen?
IchFrachMal schrieb: > Kann man das nicht einfach selber bauen? Sicher, aber eben nicht für 10 Euro. Bis jetzt sehe ich da 2 lange Zähler, einen OpAmp und das o.a. Treiber IC. Sicher könnte man die Schaltung aufnehmen - im Kopf an der Spitze wird praktisch nur die Spule sein. Ich vermute, da wird der Sensor, den der Opel anfordert (über den Blinker) über die Spule ferngespeist und somit in den Programmierzustand versetzt, was der Opel dann nutzt, um den Sensor zu lesen und anzulernen. Mit 433Mhz jedenfalls hat das kleine Gerät nichts zu tun, sondern es wird nur ein Feld zur Speisung erzeugen, ähnlich wie die Erregerspule ums Zündschloss bei Wagen mit Wegfahrsperre und Transponder im Schlüssel.
:
Bearbeitet durch User
Welches Bauteil im Bild des TOs ist die Spule?
Hartmann schrieb: > Welches Bauteil im Bild des TOs ist die Spule? Die wird an den 3-Pol Verbinder angeschlossen. Sieht man im Video und ist dort im weissen Rohr oben am Gerät. Auf den Fotos hier ist sie nicht abgebildet.
:
Bearbeitet durch User
Ich denke das dieses Gerät nur den zur "Erregung" der RDKS-Sensoren notwendigen Trägerfrequenz von 125 kHz (LF) erzeugt. Das ist ohne besondere Kodierung, einfach ein konstantes Signal. Es veranlasst den Sensor seine Sensor-ID auf dem 433 MHz Band zu senden. Die "Kodierung" erfolgt dann einfach durch erregung in einer bestimmten Reihenfolge (vorne links, vorne recht, hinten links, hinten rechts). Da das LF-Signal nur eine sehr kurze Reichweite hat, erregt es nur den Sensor vor dem man es aktiviert. Modernere, komfortablere Systeme haben hierfür durch das BCM gesteuerte Antennen in den Innenradkästen verbaut, die dieselbe Aufgabe erfüllen. Dieses LF-Signal lässt sich somit mit einer einfachen, auch diskret aufgebauten Schaltung erzeugen.
Fahr doch einfach nach Opel, Altteile Unger etc.. Einmal angelernt bleiben die das auch.
Olli Z. schrieb: > Modernere, komfortablere Systeme haben hierfür durch das BCM gesteuerte > Antennen in den Innenradkästen verbaut, die dieselbe Aufgabe erfüllen. Mein Ford Mondeo 2008 (mk4) hatte nahe jedem Rad ein Antennchen. Da war keinerlei Anlernerei oder Bedienung notwendig - Rad anschrauben, ein paar km fahren und die Luftdrücke im Borddisplay angucken. Eine Warnung erfolgte, wenn der Druck während der Fahrt abfiel, habe ich einmal erlebt. Im Autoforum war beschrieben, dass die vier Räder nacheinander abgefragt würden: Die Antenne regt die Ausendung an. Beim Nachfolger mk5 (2018) hat Ford offenbar die Kosten optimiert, da wollen die Sensoren angelernt werden, so, wie von 'Opelfahrer' beschrieben. Es sind andere Sensoren als beim mk4, nicht kompatibel. Zumindest waren sie so nett, dass das System sich zwei Satz Räder merken kann - ich kann Sommer- / Winterräder wechseln, ohne neu anzulernen. Laut mk5-Forum werden die Sensoren nicht mehr abgefragt, sondern senden zyklisch von sich aus.
Alles Schnick Schnack. Soweit ich mich erinnere, kann man bei vielen russischen LKW seit mindesten 50 Jahren die Luft während der Fahrt ablassen, oder aufpumpen.
Olli Z. schrieb: > Ich denke das dieses Gerät nur den zur "Erregung" der RDKS-Sensoren > notwendigen Trägerfrequenz von 125 kHz (LF) erzeugt. 125 kHz wären mit einem Teiler von 32 zu erreichen. Es sind jedoch zwei 4060 verbaut.
Jörg P. R. schrieb: > Fahr doch einfach nach Opel, Altteile Unger etc.. Einmal angelernt > bleiben die das auch. Bis zum Reifenwechsel im Herbst... dann geht der Spaß wieder von vorn los. Die Fahrzeuge haben in der Regel nur 4 Sensor-Speicherplätze. Naja, Premium-Marken werden vermutlich mehr können...
Bafon schrieb: > Es sind jedoch zwei 4060 verbaut. einer wird vermutlich dafür da sein, das die LED so ansprechend flackert, denn das tut sie ja mit deutlich niedrigerer Frequenz. pegel schrieb: > Alles Schnick Schnack. > > Soweit ich mich erinnere, kann man bei vielen russischen LKW seit > mindesten 50 Jahren die Luft während der Fahrt ablassen, oder aufpumpen. Ach, und das ist dann kein Schnick Schnack? Statt diesem ganzen RDKS System wäre es sicher einfacher, 1 mal im Monat den Reifendruck zu prüfen. Ist auch billiger und man hat wenigstens etwas Bewegung.
:
Bearbeitet durch User
Manfred schrieb: > Mein Ford Mondeo 2008 (mk4) hatte nahe jedem Rad ein Antennchen. Da war > keinerlei Anlernerei oder Bedienung notwendig - Rad anschrauben, ein > paar km fahren und die Luftdrücke im Borddisplay angucken. Eine Warnung > erfolgte, wenn der Druck während der Fahrt abfiel, habe ich einmal > erlebt. Genau das habe ich doch bechrieben?! :-) Meiner hat das ja auch, habs selbst nachgerüstet und sowohl mit als auch ohne betrieben. Daher weiss ich es ja. > Zumindest waren sie so nett, dass das System sich zwei Satz Räder merken > kann - ich kann Sommer- / Winterräder wechseln, ohne neu anzulernen. Ja, das reicht ja eigentlich auch dann. > Laut mk5-Forum werden die Sensoren nicht mehr abgefragt, sondern senden > zyklisch von sich aus. Das tun sie ohnehin. Die haben intern einen G-Sensor und senden, sobald eine gewisse Radgeschwindigkeit erreicht ist. Die RDKS-Sensoren im Rad unterscheiden sich sicherlich inhaltlich im Protokoll, das Prinzip dürfte aber überall dasselbe sein. Übrigends lassen sich die Sensoren in der Regel auch selbst "programmieren". Um z.b. die Notwendigkeit eines anlernens am Fahrzeug zu entzerren wird dann die ID eines neuen Sensors auf die eines alten eingestellt. Interessant fände ich herauszufinden, wie ein LF-Erreger aufgebaut werden muss um einen Sensor dazu zu bringen seine Daten zu senden. Würde auch helfen solche Sensoren ausserhalb vom Fahrzeug zu überprüfen. Eine entsprechende Empfangseinrichtung vorausgesetzt. Im Ford wird das übrigens über den Empfänger der Funkfernbedienung erledigt.
Matthias S. schrieb: > Bafon schrieb: >> Es sind jedoch zwei 4060 verbaut. > > einer wird vermutlich dafür da sein, das die LED so ansprechend > flackert, denn das tut sie ja mit deutlich niedrigerer Frequenz. Extra 4060 um eine LED flackern zu lassen? Bin ich etwas skeptisch. Im Bild des TOs sehe ich auch nur eine Anzapfung an Pin 2 des oberen 4060 (Q12).
Matthias S. schrieb: > Ach, und das ist dann kein Schnick Schnack? Eher nicht. Damit kann man beim LKW je nach Ladung das Fahrverhalten beeinflussen. Beim PKW sehe ich allerdings auch keinen rechten Sinn. Wenn ich einmal ums Auto laufe, sehe ich was los ist. Und wenn ich es nicht vergesse, prüfe ich die Luft alle paar Wochen an der Tanke.
Ach ja, was ist eigentlich mit dem Reserverad? ;)
Bafon schrieb: > Extra 4060 um eine LED flackern zu lassen? Bin ich etwas skeptisch. Warum nicht? Immerhin geht Pin 5 (Q5) des unteren 4060 über die 0-Ohm Brücke und R201 direkt an die grüne LED. Allerdings wird auch Q12 benutzt und verschwindet unter dem Elko. Vielleicht muss das 125kHz Signal zyklisch getaktet werden. Der OpAmp steuert die LowBatt LED an.
Matthias S. schrieb: > Ach, und das ist dann kein Schnick Schnack? Statt diesem ganzen RDKS > System wäre es sicher einfacher, 1 mal im Monat den Reifendruck zu > prüfen. Ist auch billiger und man hat wenigstens etwas Bewegung. Ich denke das ist eine falsche Betrachtungsweise des Systems. Das ist ja doch keine Komfortfunktion die einen möglichst optimalen Reifenabrieb zur Folge hat, sondern ein Sicherheitsmerkmal, damit man nicht mit halbplattem Reifen losfährt oder bei starkem Druckverlust während der Fahrt warnt. Nicht ohne Grund ist das System bei Fahrzeugen ab Baujahr 1. Nov 2014 PFLICHT.
Matthias S. schrieb: > benutzt und verschwindet unter dem Elko. Vielleicht muss das 125kHz > Signal zyklisch getaktet werden. Mit Sicherheit ist das so. Gibt es evtl. darüber Infos im Netz oder hat jemand solche? Auch aus dem funktionsfähigen Gerät könnte man mittels LA oder DSO vor der Antennenendstufe mal messen. Mittels eines DVB-T Empfängers kann man auch mal überprüfen ob ein solcher Sensor dann auch was sendet, wenn ein echtes Empfangsgerät gerade nicht zur Hand ist.
:
Bearbeitet durch User
Olli Z. schrieb: > damit man nicht mit > halbplattem Reifen losfährt oder bei starkem Druckverlust während der > Fahrt warnt. Wenn man sich vor Beginn der Fahrt vom Zustand des Fahrzeuges überzeugt (wie in §23 der StVO ja auch beschrieben), ist das unnötig. Die Nummer ist für Tussen, die sich mit Autos nicht auskennen und erfunden von Leuten, die noch mehr Mäuse machen wollen. Technikverliebter Unsinn um einen Grund zu haben, den Kunden vom Selberwechseln der Reifen abzuhalten.
:
Bearbeitet durch User
Matthias S. schrieb: > Wenn man sich vor Beginn der Fahrt vom Zustand des Fahrzeuges überzeugt > (wie in §23 der StVO ja auch beschrieben), ist das unnötig. Die Nummer Du vermischst hier die Anforderungen ans Fahrzeug mit denen an den Fahrer. Wenn es um den Fahrer geht hast Du recht. Beim Fahrzeug ist es wie ich geschrieben habe EU-Weit Pflicht. > einen Grund zu haben, den Kunden vom Selberwechseln der Reifen > abzuhalten. Zumindest ist das ein nicht ganz ungern gesehener Nebeneffekt, da stimme ich Dir zu ;-) Fragt sich wann Radschrauben erfunden werden die sich nur noch elektronisch von der Werkstatt öffnen lassen... oder Reifen die sich nicht mehr mit der Felge koppeln weil nicht vom Hersteller gewünscht ;-) Aber neben dem rechtlichen Firlefanz geht es hier doch um Technik. Und zum glück muss das hier im Forum keinen "Sinn" machen und sich auch nicht "rechnen müssen". Will sagen, last uns doch einfach mal spielen mit den Möglichkeiten :-) Ich fänds klasse wenn der TO aus seiner Platine mal einen schaltplan generieren würde. Das wird ja vermutlich nur eine einfache doppelseitige Platine sein und kein Multilayer. Man könnte die Bauteile also mal runterlöten und die Kontakte durchmessen oder mit nem Scanner digitalisieren und reverse engineeren. Dann wär auch die Funktion klarer. Von den wenigen Bauteilen her wäre auch ein Aufbau auf dem Steckbrett dann möglich. Ich glaub ich bestell mir einfach mal so ein Ding und zerleg es selbst. Kostet ja nur nen 10er (direkt aus China sogar ab 2,80€!), dafür bekommt man nichtmal die Bauteile um sowas selbst aufzubauen. Der Erkenntnissgewinn ist mir das allemal wert. Leider klappt das Ding wohl nicht für meinen Ford-Sensor den ich hier liegen hab. Da brauche ich wohl eher dieses https://www.ebay.de/itm/Fit-Fur-Ford-Reifendruckkontrollsystem-TPMS19-Sensor-Programm-Tool-8C2Z1A203A/333446076262 Und das sieht nicht aus als wäre es diskret aufgebaut, da wird vermutlich nur ein schwarzer Klecks im Gehäuse versteckt sein... Gut möglich das es sogar dasselbe macht wie das Opel-Tool. Man wird sehen.
:
Bearbeitet durch User
Ah, gibt doch genau dasselbe auch für Ford: https://www.ebay.de/itm/EL-50449-EL50449-TPMS-Reset-Tool-Reifenwachter-Drucksensor-Aktiviert-KQ/184201310179 Ist EL-50449 anstelle EL-50448. Wenn es überhaupt einen Unterschied gibt, dann wohl nur im Timing des Signals.
pegel schrieb: > Alles Schnick Schnack. Das kann nur jemand schreiben, dem Erfahrung fehlt oder [unfreundliche Worte verkniffen]. Ich hatte einmal einen Reifenschaden auf der Autobahn und war danach zufrieden, trotz Eiertanz unbeschadet durch die Abfahrt gekommen zu sein. Der Reifen war natürlich Schrott. Viele Jahre später habe ich beim Neuwagen das RDKS als Zusatzausstattung bestellt. Das hat dann irgendwann gewarnt, eine Schraube im Profil gefunden - ohne kritische Situation und der Reifen war reparierbar. Das ist eine sinnvolle Sache, ärgerlich sind die Mehrkosten. Olli Z. schrieb: > Die RDKS-Sensoren im Rad unterscheiden sich sicherlich inhaltlich im > Protokoll, das Prinzip dürfte aber überall dasselbe sein. Übrigends > lassen sich die Sensoren in der Regel auch selbst "programmieren". Um > z.b. die Notwendigkeit eines anlernens am Fahrzeug zu entzerren wird > dann die ID eines neuen Sensors auf die eines alten eingestellt. Ich denke, dass bei Fahrzeugen mit vier Einzelantennen die Sensoren keine ID haben, weil das Auto ja weiß, welchen es gerade fragt. Über die Programmierbarkeit der Sensor-ID neuerer Versionen habe ich gelesen. Ich glaube allerdings, dass das nur auf die Zweitausrüster zutrifft, nicht die original vom Fahrzeughersteller gelieferten? Olli Z. schrieb: > Kostet ja nur nen 10er (direkt aus China sogar ab 2,80€!), dafür bekommt > man nichtmal die Bauteile um sowas selbst aufzubauen. Der > Erkenntnissgewinn ist mir das allemal wert. > > Leider klappt das Ding wohl nicht für meinen Ford-Sensor den ich hier > liegen hab. 2,80 plus Versandkosten, die Richtung 10 Euro passt schon. Mal kurz bei Aliexpress geschaut, finde ich zwei Versionen: Opel (GM) und Ford. Selbst innerhalb einer Baureihe kann es einen anscheißen, zumindest Ford hat beim Mondeo mk5 mindestens zwei verschiedene Sensorversionen und auch Unterschiede im Bordcomputer. Wenn man mal µC-net durchsucht, ist das nicht der erste Thread zum Thema RDKS, das mutiert zum Ärgenis für den Endkunden.
Manfred schrieb: > Beim Nachfolger mk5 (2018) hat Ford offenbar die Kosten optimiert, da > wollen die Sensoren angelernt werden so wie beim Fiesta FL 2016 deswegen habe ich die Sensoren für die Winterreifen clonen lassen damit ich frei wechseln kann ohne Besuch beim Händler!
Joachim B. schrieb: > deswegen habe ich die Sensoren für die Winterreifen clonen lassen Stammen die aus dem Nachrüstmarkt freier Händler oder sind das 'Originalteile'?
Manfred schrieb: > Stammen die aus dem Nachrüstmarkt freier Händler oder sind das > 'Originalteile'? die hatte mein bevorzugter Reifenhändler gleich mit meinen Wunschfelgen bestellt. Dummerweise kamen die unprogrammiert, waren aber clonebar mit einem Programmiergerät, hat halt nicht jeder Händler, Originalsensoren pro Rad ausgelesen und genauso pro WinterRad wieder programmiert. Somit bin ich frei selber zu wechseln oder mir jeden beliebigen Dienstleister zu meiner WunschZeit zu suchen.
Manfred schrieb: > Joachim B. schrieb: >> deswegen habe ich die Sensoren für die Winterreifen clonen lassen > > Stammen die aus dem Nachrüstmarkt freier Händler oder sind das > 'Originalteile'? PS Ford wollte für "ORIGINAL Winterräder" erst mal mehr GELD und 2tens bei jedem Wechsel einen Werkstattbesuch, weil keine 2 Reifensatzsensoren angeblich einprogrammierbar sein sollen!
Manfred schrieb: > pegel schrieb: >> Alles Schnick Schnack. > > Das kann nur jemand schreiben, dem Erfahrung fehlt oder [unfreundliche > Worte verkniffen]. Na ja. Ich habe mit verschiedenen Autos jeweils km mäßig mehrfach die Welt umrundet. Welche Erfahrung soll das sein? Reifenplatzer bei 200km/h? Stimmt, diese Erfahrung fehlt mir.
Hier ist doch das Mikrocontroller-Forum und nicht Honkbook?! Lasst uns doch bitte bei der Sache bleiben, der Technik und nicht in Trivialitäten abrutschen und über Kaisers Bart diskutieren. Wer hat denn Konkret WISSEN um die exakte Funktionsweise dieser Technik? Hier wohl im besonderen Ford/Opel. Um überhaupt die Funktion eines RDKS-Sensor Erregers nachweisen zu können müsste man als erstes seine eigene Aussendung kontrollieren und ggf. auch interpretieren können. So ein Sensor überträgt neben seiner Id um dem Luftdruck noch weitere Parameter. Auch scheint er in der Lage zu sein Daten für eine Programmierung zu empfangen. Das Frequenzband ist ja vorgegeben. Geklärt werden müsste die Modulation (FSK, AM, FM, ...) um überhaupt an Symbole zu kommen. Dann die Frage welche Symbole welchen Bitzuständen entsprechen. Daraus könnte man dann ggf. das Protokoll ermitteln...
Am einfachsten wäre wohl um die Sendespule einen Draht zu wickeln und am DSO die Signale ansehen. Damit dürfen keine Fragen offen bleiben.
Olli Z. schrieb: > Auch scheint er in der Lage zu > sein Daten für eine Programmierung zu empfangen. Nö, denn der 'Programmierer' ist ja das o.a. Gerät und das überträgt keinerlei Codes fürs Programmieren an den Sensor, sondern lediglich Energie, damit der Sensor anfängt, seine ID abzustrahlen. Die schluckt der Opel und quittiert mit der Hupe. Dann ist der nächste Sensor an der Reihe, den der Opel mit dem Blinker anzeigt. Die Sensoren im Opel sind anscheinend sonst 'self-powered' und übertragen ab und zu mal Daten ans Fahrzeug, mögl. eben angeregt durch Radbewegungen oder sonst was. Ob sie eine Batterie haben oder Harvesting machen, ist dabei unwichtig. pegel schrieb: > Am einfachsten wäre wohl um die Sendespule einen Draht zu wickeln und am > DSO die Signale ansehen. So isses. Aber leider ist ja das Gerät des TE defekt und ob er ein Oszi hätte, wissen wir nicht. Mein Youngtimer jedenfalls kann mit RDKS nicht dienen - ein Glück.
:
Bearbeitet durch User
Über die Sensoren kommt man auch an sehr wertvolle Informationen ran. Ich nutze bei Dingen die irgendeine Funkschnittstelle haben nämlich gern die FCC ID, welche vorhanden und angegeben sein muss, wenn verfügbar sogar in der Betriebsanleitung oder Beiblatt. Ganz sicher ab auf dem Gerät selbst. Habe hier mal das Bild von einem Sensor für meinen Ford abgebildet den ich übrig habe. Diese Nummer dann in der Suche https://fccid.io/ eingegeben liefert interessantes zutage. https://fccid.io/KR5S180020 - Stromversorgung 3V (CR2450) - Sensoren für Luftdruck, Temperatur und Beschleunigung - Sensor-ID 32 Bit lang - RF-Transmitter - Trägerfrequenz 433,92 MHz - Modulation FSK - Übertragungsrate 9600 Baud - Manchester-Kodierung - RF-Receiver (über den erfährt man im Dokument nichts, weil nur Sender zulassungspflichtig sind) Anschließend folgt in „DUTY CYCLE CALCULATION“ auch gleich Klarheit darüber, wann und wie oft der Sensor in Betrieb geht und damit die durchschnittliche Arbeitszeit (Dutyclycle): - PARKING: 1 burst transmission every 13H + 1 WUP transmission - FIRST BLOCK: During 2 minutes after vehicle start, burst emission every 16.8s (8 burst emission) - INTERIM FIRST BLOCK: none transmission - DRIVING: 1 burst emission every 67.2s during the rest of the hour (54 burst emission) - INTERIM: none transmission ⇒ During 1 hour, the Wheel Unit transmits 63 bursts + 1 WUP. 1 burst = 30.29806ms MAX 1 WUP length max = 42.1ms MAX ⇒ total transmission during 1 hour = 63 x 30.29806ms + 42.1ms = 1.96s DUTY CYCLE = (1.96 / 3600) x 100% = 0.06% Externe Ereignisse wären die Triggerung durch das Wakeup-Signal eines 125 khz Senders, ein signifikanter Druck- oder Temperaturunterschied oder auftretende G-Kräfte durch Rotation. Wird ein Luftdruck über 1.5 Bar gemessen, oder wurde der Sensor durch ein LF-Signal „eingeschaltet“ (Power-on command), befindet er sich im „Initial mode“ (Initialisierungsmodus). In diesem Zustand mißt und sendet er alle 0,85 Sekunden seine Sensorwerte. Insgesamt macht er das 256 mal hintereinander, also über einen Zeitraum von fast 4 Minuten . Diese Sequenz dient u.a. zur Funktionskontrolle und zum anlernen eines Sensors am Fahrzeug. Anschließend wechselt er in den „Normal mode“. Im „Normal mode“ (Normalmodus) wird der Reifendruck alle 3,4 Sekunden gemessen und alle 60 Sekunden gesendet. Weicht der alle 3,4 Sekunden gemessene Luftdruck um 200 mBar (20 kPa) vom vorherigen ab (positiv wie negativ), tritt der Sensor in den „Pressure alter mode“ (Druckalarmmodus) ein. In diesem Zustand arbeitet der Sensor wie im „Inital mode“, also mit rascher Messung und häufigen Übertragungen. Dies soll einen schnellen Druckabfall signalisieren und der Fahrzeugsteuerung einen rechtzeitigen Warnhinweis oder sogar Eingriff (ESP, ABS-Eingriff oder Temporeduktion) geben. Ein spezieller „High temp alert mode“ (Übertemperaturmodus) wird ab einer Umgebungstemperatur von 120° aktiviert. Auch hier verhält sich der Sensor wie im „Initial mode“. Diese Temperaturen könnten durch eine Beschädigung am Reifen, Bremsen oder Radlager entstehen. Anbei noch ein paar Bilder vom einem Teardown eines solchen Sensors.
:
Bearbeitet durch User
Ich habe mal den Empfänger der im Ford zum Einsatz kommt untersucht. Er wird einzig über LIN mit dem BCM verbunden. Das Innenleben ist übersichtlich. Wenn ich den Empfänger mit 12V versorge kommt für wenige Sekunden eine Kommunikation auf dem LIN am DSO zum Vorschein. Werde die mal vor dem LIN-Transceiver (TTL-Pegel) mit dem LA aufzeichnen. Habe auch schonmal meinen Funkschlüssel in der Nähe senden lassen, aber auf dem LIN tut sich erstmal nichts. Ich vermute das der Empfänger erst mit dem Steuergerät (BCM) reden muss um überhaupt betriebs und empfangsbereit zu sein...
Olli Z. schrieb: > Bilder Auf jeden Fall ein anderer als im Vorgänger Mondeo-mk4. (Anhang aus einen Winterkomplettrad 11/2008) Olli Z. schrieb: > Ich habe mal den Empfänger der im Ford zum Einsatz kommt In welchem Modell / Baujahr?
Manfred schrieb: > Auf jeden Fall ein anderer als im Vorgänger Mondeo-mk4. > (Anhang aus einen Winterkomplettrad 11/2008) Die RDKS-Sensoren sind in der gesamten MK4 Modellreihe vom Mondeo gleich, also vom ersten vorFacelift 2007 bis zum letzten Facelift in 2014. Mit "gleich" meine ich dabei das Funkprotokoll um das es hier geht. > Olli Z. schrieb: >> Ich habe mal den Empfänger der im Ford zum Einsatz kommt > In welchem Modell / Baujahr? Auch der ist in allen MK4 Modellen gleich (inkl. Galaxy, S-Max).
So, habe inzwischen auch den o.g. LF-Sender erhalten. Habe mir noch eine andere Variante davon zum Vergleich mitbestellt. Nun würde ich dem ganzen gern funktechnisch auf den Zahn fühlen, aber dazu mach ich wohl besser einen eigenen Thread im HF-Forum auf.
Ich habe mir in mein Auto ein Amateurfunkgerät eingebaut, weil ich sehr viel auf den Autobahnen unterwegs bin. Gerade in Bayern und in NRW kommt es immer wieder vor das es Autofahrer gibt die einem zeigen das 80 völlig ausreichend ist (obwohl 130 in NRW und offen in Bayern) und dann auf der linken Spur dahin gurken. Das es Nötigung ist, ist allen bewusst, aber ich will keinen anzeigen. Macht sowieso mehr Aufwand als bei einem Funkgerät die Sendetaste zu drücken (eigentlich ein Schalter der Mittelkonsole, welche es aufgrund meiner Ausstattung so nicht geben würde, habe ich eingebaut und zweckentfremdet). Wenn es ein neuer Ford ist, schalte ich das Funkgerät auf Senden (433,905 MHz) und warte so lange bis der Bordcomputer des Vorausfahrenden aufgrund des Signalverlustes der Drucksensoren eine Warnung im Tacho anzeigt. Die fahren dann zum wiklich größten Teil dann rechts raus (vermuten einen Reifendefekt). Herausgefunden hat das ein Freund von mir der Amateurfunker ist und einen Ford fuhr. Jedesmal danach musste er in die Werkstatt zum Fehlerlöschen. Zumindest Ford-Fahrer kann ich dazu bringen sich von der linken Spur "fort-bewegen"!
Auch wenn ich Deine Methode mehr als zweifelhaft finde, weil es im Vergleich zur angesprochenen Nötigung in Deinem Fall gleich ein gefährlicher Eingriff in den Straßenverkehr ist, sollte das zeigen das das Thema Funk durchaus heikel ist. Ich habs bei meinem nie probiert das so zu DoS'en, kann es also weder bestätigen noch dementieren. Von der Sache her könnte es funktionieren. Aber das ist hier ja eigentlich nicht der Punkt... :-)
Opelfahrer schrieb: > Ich habe das gleiche Problem (Gerät funktionier scheinbar nicht Es wird auch nicht kaputt sein. Es taugte schon bei Lieferung nichts. Da gibt es nichts zu reparieren. Zurückschicken, Geld zurück, negative Bewertung schreiben, und das nächste Mal dran denken: ein kompletter TPMS ist billiger als irgendein proprietärer Scheiss des Autoherstellers.
Scheinbar habe die Autos mit dem Stern vorn jedenfalls eine andere Technik verbaut. Als ich für meinen neue Winterreifen auf gebrauchten original Mercedes Alufelgen mit Reifendrucksensoren gekauft habe, war mein Auto 15km weit beleidigt mit mir und hat danach die neuen Sensoren übernommen. Beim zurück Wechsel auf die Sommerreifen ging die Anzeige sofort wieder. Ob man das nun braucht kann ich auch nicht sagen, ich hatte schon diverse Reifenpannen bis zur Explosion eines Reifens bei 160km/h auf der Vorderachse, das Auto stand dann auf der zerstörten Felge ohne Reifen, manchmal hab ichs bei Losfahren gemerkt, manchmal erst nach mehreren hundert Kilometern fahrt wobei ich sicher bin mit genug Druck in dem Reifen los gefahren zu sein. Saubere Hände behält man beim Mercedes jedenfalls sich und recht genau sind die Werte im Bordcomputer auch. Und meine Reifen wechsele ich auch selbst, die Wagenheber Aufnahme von Mercedes war eine größere Herausforderung. Mercedes liefert auch weder Heber noch Kompressor oder Reserverad mit. MfG Michael
Michael_Ohl schrieb: > Scheinbar habe die Autos mit dem Stern vorn jedenfalls eine andere > Technik verbaut. Als ich für meinen neue Winterreifen auf gebrauchten > original Mercedes Alufelgen mit Reifendrucksensoren gekauft habe, war > mein Auto 15km weit beleidigt mit mir und hat danach die neuen Sensoren > übernommen. Beim zurück Wechsel auf die Sommerreifen ging die Anzeige > sofort wieder. Nö, dieser ganze Kram ist einfach nur schlampig umgesetzt. Vor Jahren erzählte ein Kollege, dass der neue Benz seiner Frau eine Reifendrucküberwachung hat und fand im Internet Bilder, die fast gleich meinem 2008er Ford aussahen. Ich habe nun einen Ford von Anfang 2018, wo man Kosten sparen wollte und das System deutlich zickig ist: 2018 Sommerräder drauf, alles gut. Ende 18 Winterräder drauf, 2019 wieder Sommerräder, dann Winterräder. Diesen Mai wieder auf Sommer und nun erstmalig Zickerei. Menue - Einstelungen ... initialisieren, sinnvolle Werte im Display. Ein paar km später "Fehlermeldung RDKS" ... das habe ich mehrfach gespielt und mir ein Anlerngerät bestellt. Nach ein paar Tagen war dann auf einmal Ruhe, schlüssige Werte im Display und keine Fehlermeldung mehr. Das Anlerngerät werde ich erstmal nicht ausprobieren, da es sich ja 'wie von Wunderhand' selbst bereinigt hat. Ich gehe davon aus, dass beide die stationäre Seite von Contitech zuliefern lassen und vergleichbar schlampig implementiert sind! Wenn das Internet nicht lügt, gibt es nur zwei Lieferanten: Contitech und Valeo aus Frankreich.
Olli Z. schrieb: > Nun würde ich dem ganzen gern funktechnisch auf den Zahn fühlen, aber > dazu mach ich wohl besser einen eigenen Thread im HF-Forum auf. Hier hat das jemand für den Renault-ZOE gemacht, die Details stehen dabei: https://canze.fisch.lu/taking-tpms-a-bit-further/
Über diesen Thread Beitrag "Signal im 125 kHz Band mit SDRsharp aufzeichnen" habe ich nun mittels SDRplay (RSP2) und einer RFID-Rahmenantenne das Signal des Handsenders aufnehmen können. Da ich kein "Original"-Gerät zur Hand habe ist schwer zu sagen ob das nun gültig ist oder nicht. Da ich sowohl einen RDKS-Sensor übrig habe, als auch einen Satz Winterreifen mit Sensoren im Keller, war meine Idee das wenn der Sender funktionieren sollte, müsste ich ja auf dem 433 MHz-Band die Antworten vom Sensor erkennen können. Dazu habe ich die Platine aus ihrem Gummipanzer befreit, soweit das möglich war (womit bekommt man so ein Gummi-Zeuchs ordentlich runter? Hitze kann ihm nix anhaben, Alkohol auch nicht...) Dann habe ich die Batterie gemessen (war ok, 3V) und ein Amperemeter zwischengeschaltet. Ich sehe so alle paar Sekunden eine Stromaufnahme von ca. 0,058 mA (58 µA). Zum senden ist das etwas arg wenig. Sobald ich aber den Handsender betätige, steigt die Stromaufnahme während diesem Intervall immerhin auf 0,200 mA. Meine Vermutung ist, das der Sensor sich erst vollständig aktiviert, wenn er einen entsprechend hohen Druck misst (ab 1,5 Bar) weil die Dinger sonst beim Transport bzw. im Lager auch lustig vor sich hin funken würden und die Batterie leer geht. Und zum kurz aufwachen und Luftdruck messen reicht der Strom sicherlich.
:
Bearbeitet durch User
Zum Vergleich: das EL-50448 für GM/Opel erzeugt auf Tastendruck ein unmoduliertes 125 kHz Signal für ca. 4 Sekunden. Das Timing (LF, Blinken der grünen LED, Ausschalten nach ca. 4 Sekunden) wird über die Zähler von dem 4 MHz Quarz abgeleitet. Der OpAmp ist scheinbar nur für die "Low Bat" Anzeige (rote LED) zuständig. Interessant wäre was in dem EL-50449 für Ford drinnen ist um die Modulation zu erzeugen.
Dieter schrieb: > Interessant wäre was in dem EL-50449 für Ford drinnen ist um die > Modulation zu erzeugen. Oh ja, damit kann ich selbstverständlich dienen ;-) Es scheint als wäre der Hersteller hier völlig neue Wege geganen und setzt nun auf µC (12F508) anstelle diskrete ICs. Der ganze TX dauert 5 Sekunden.
:
Bearbeitet durch User
Olli Z. schrieb: > > Es scheint als wäre > der Hersteller hier völlig neue Wege geganen und setzt nun auf µC > (12F508) anstelle diskrete ICs. Mit einem Logic Analyzer könntest Du das mit SDRPlay aufgezeichnete Signal verifizieren. Der PIC wird ziemlich sicher das vollständige Signal erzeugen (bei 125 kHz ja kein Problem), nicht nur die Modulation.
Zu dem Signal aus EL-50449_singleframe.png: Schau Dir mal im Datenblatt des SP40T (Infineon-SP400-15-11-DataSheet-v01_01-EN.pdf) auf Seite 54 "Figure 5-17 LF telegram modulated on a 125 kHz carrier" an. Das passt ganz gut: - 17 Bits Preamble - Synchronization pattern (laut Datenblatt fest vorgegeben) - 32 Bits Daten (Manchester codiert) Ich vermute stark dass einiges vom SP40T auch für den Chip in Deinem Sensor passt. Die im Datenbatt erwähnte LF Baudrate "typical Baud-rate of 3900 bit/s" kommt auch einigermassen hin. Schöner sehen würde man das Ganze natürlich in einem Trace vom Signal am PIC mit dem Logic Analyzer (siehe oben).
Hallo (auch und besonders Dieter), ich wärme mal wieder :-) Anbei ein DSO-Scan eines vollständigen Datagramms inklusive Preambel, gemessen an der LF-Antenne. Und dann noch eins mit dem Timing der Preambel. Dann habe ich einfach mal den PIC12F508I runtergelötet und auf gut glück ausgelesen. Zumindest kommt was (nicht nur 0x00 oder 0xFF) und der PIC-Disasm v1.6 macht dieses daraus
1 | ; original File = D:\IONOS HiDrive\Auto\Thema\RDKS\TPMS-Trigger Tool\tpms-trigger-tool_small.hex |
2 | |
3 | processor 12F508 |
4 | #include <P12F508.INC> |
5 | __config _MCLRE_OFF & _CP_ON & _WDT_ON & _XT_OSC ; 0x0FE5 |
6 | ; __idlocs 0xFF, 0xFF, 0xFF, 0xFF |
7 | |
8 | ; RAM-Variable |
9 | LRAM_0x08 equ 0x08 |
10 | LRAM_0x09 equ 0x09 |
11 | |
12 | ; Program |
13 | |
14 | Org 0x0000 |
15 | |
16 | ; Reset-Vector |
17 | NOP |
18 | MOVWF OSCCAL |
19 | GOTO LADR_0x0014 |
20 | XORLW 0xFF ; b'11111111' d'255' |
21 | XORLW 0xFF ; b'11111111' d'255' |
22 | XORLW 0xFF ; b'11111111' d'255' |
23 | XORLW 0xFF ; b'11111111' d'255' |
24 | ADDWF PCL,F ; !!Program-Counter-Modification |
25 | RETLW 0xA4 ; b'10100100' d'164' |
26 | RETLW 0x36 ; b'00110110' d'054' "6" |
27 | RETLW 0x2B ; b'00101011' d'043' "+" |
28 | RETLW 0x00 ; b'00000000' d'000' |
29 | XORLW 0xFF ; b'11111111' d'255' |
30 | XORLW 0xFF ; b'11111111' d'255' |
31 | XORLW 0xFF ; b'11111111' d'255' |
32 | XORLW 0xFF ; b'11111111' d'255' |
33 | ADDWF PCL,F ; !!Program-Counter-Modification |
34 | RETLW 0x05 ; b'00000101' d'005' |
35 | RETLW 0x00 ; b'00000000' d'000' |
36 | RETLW 0x00 ; b'00000000' d'000' |
37 | LADR_0x0014 |
38 | CALL LADR_0x0016 |
39 | GOTO LADR_0x0148 |
40 | LADR_0x0016 |
41 | MOVLW 0x04 ; b'00000100' d'004' |
42 | MOVWF GPIO |
43 | MOVLW 0x08 ; b'00001000' d'008' |
44 | TRIS GPIO |
45 | MOVLW 0x4F ; b'01001111' d'079' "O" |
46 | OPTION |
47 | MOVLW 0x07 ; b'00000111' d'007' |
48 | MOVWF FSR |
49 | CLRF INDF |
50 | LADR_0x001F |
51 | INCF FSR,F |
52 | CLRF INDF |
53 | MOVLW 0xFF ; b'11111111' d'255' |
54 | SUBWF FSR,W |
55 | BTFSS STATUS,Z |
56 | GOTO LADR_0x001F |
57 | RETLW 0x00 ; b'00000000' d'000' |
58 | MOVWF LRAM_0x09 |
59 | LADR_0x0027 |
60 | CALL LADR_0x0030 |
61 | CALL LADR_0x0030 |
62 | CALL LADR_0x0030 |
63 | CALL LADR_0x0030 |
64 | DECFSZ LRAM_0x09,F |
65 | GOTO LADR_0x0027 |
66 | RETLW 0x00 ; b'00000000' d'000' |
67 | MOVLW 0x64 ; b'01100100' d'100' "d" |
68 | GOTO LADR_0x0031 |
69 | LADR_0x0030 |
70 | MOVLW 0xFA ; b'11111010' d'250' |
71 | LADR_0x0031 |
72 | MOVWF LRAM_0x08 |
73 | DECF LRAM_0x08,F |
74 | LADR_0x0033 |
75 | CALL LADR_0x003A |
76 | DECFSZ LRAM_0x08,F |
77 | GOTO LADR_0x0033 |
78 | CALL LADR_0x003C |
79 | RETLW 0x00 ; b'00000000' d'000' |
80 | NOP |
81 | GOTO LADR_0x003A |
82 | LADR_0x003A |
83 | GOTO LADR_0x003B |
84 | LADR_0x003B |
85 | NOP |
86 | LADR_0x003C |
87 | NOP |
88 | NOP |
89 | MOVLW 0xC5 ; b'11000101' d'197' |
90 | GOTO LADR_0x0041 |
91 | NOP |
92 | LADR_0x0041 |
93 | (jede Menge NOPs) |
94 | LADR_0x0148 |
95 | (jede Menge NOPs) |
96 | MOVLW 0x22 ; b'00100010' d'034' """ |
97 | End |
Den ersten Teil würde ich so interpretieren:
1 | LADR_0x0014 |
2 | CALL LADR_0x0016 ; Init chip |
3 | GOTO LADR_0x0148 |
4 | |
5 | LADR_0x0016 |
6 | MOVLW 0x04 ; b'0000 0100' |
7 | MOVWF GPIO ; Set GP2 (Pin 5) to HIGH |
8 | |
9 | MOVLW 0x08 ; b'0000 1000' |
10 | TRIS GPIO ; Set GP3 (Pin 4) to Tri-State (Open) |
11 | |
12 | MOVLW 0x4F ; b'0100 1111' |
13 | OPTION ; Set presacler (PSA=1, PS2=1, PS1=1, PS0=1) |
14 | ; Set T0CS=0, T0SE=0 |
15 | ; Set /GPWU=0, /GPPU=1 |
16 | |
17 | ; Das sieht so aus als würde er das RAM initialisieren und zurück zum LADR_0x0014 springen, |
18 | ; wo er dann nach LADR_0x0148 wechselt |
19 | MOVLW 0x07 ; b'00000111' d'007' |
20 | MOVWF FSR ; Set File-Select-Register (in fact a pointer) to 0x07 |
21 | CLRF INDF ; Clears INDF register |
22 | LADR_0x001F |
23 | INCF FSR,F |
24 | CLRF INDF |
25 | MOVLW 0xFF ; b'11111111' d'255' |
26 | SUBWF FSR,W |
27 | BTFSS STATUS,Z |
28 | GOTO LADR_0x001F |
29 | RETLW 0x00 ; Return from call |
30 | |
31 | MOVWF LRAM_0x09 ; sinnlose operation da nie ausgeüfhrt |
Ich nehme an das man mit dem Knopf den RESET des Chips triggert und dann läuft einmal die ganze Prozedur ab. Der externe 4 MHz Oscillator auf der Platine geht direkt an die Pins 2+3 (OSC IN) vom PIC.
:
Bearbeitet durch User
Ich habe mir das Timing vom "datagram.png" mal etwas näher angesehen. Der PIC erzeugt über den Code das in "pulse.png" gezeigte Grundsignal, welches in Puls/Pause 8 µS lang ist und somit einer Grundfrequenz von 125 kHz entspricht. 1 Impuls ist dabei 1 µS lang, gefolgt von einer Pause mit 7 µS. Das Signal vom PIC treibt dabei die Sendeantenne, wird also aufgrund von LCR-Eigenschaften zu einem mehr oder weniger sinusförmigen Sendesignal. Die einzelnen Blöcke in "datagram.png" bestehen dann eben aus einer gewissen Anzahl dieser Impulse. Ich habe mir mal die vorkommenden Blöcke genauer angesehen und nachgezählt/gemessen und den verschiedenen mal diese Symbole zugeordnet: K = 16 Impulse (120 µS) + 134 µS Pause K' = 16 Impulse(120 µS) + 262 µS Pause M = 32 Impulse(248 µS) + 262 µS Pause M' = 32 Impulse(248 µS) + 138 µS Pause L = 48 Impulse(376 µS) + 376 µS Pause Das ergibt dann übersetzt auf das datagram.png folgende Sendefolge: Sync = 17 x K Data = L K M M K K' M K M M' K' M K M M M M M K K M M M M Was Dieter hier schon vor längerer Zeit mitteilte... Dieter schrieb: > im Datenblatt des SP40T (Infineon-SP400-15-11-DataSheet-v01_01-EN.pdf) > auf Seite 54 "Figure 5-17 LF telegram modulated on a 125 kHz carrier" an. > Das passt ganz gut: > - 17 Bits Preamble > - Synchronization pattern (laut Datenblatt fest vorgegeben) > - 32 Bits Daten (Manchester codiert) Ein "K" entspricht also einem Bit. Da es am PIC also ein bereits moduliertes Signal gibt kann mein Siglent leider keinen Manchester-Decode durchführen, oder ich habe die richtige Einstellung dazu noch nicht gefunden. Evtl. teste ich das nochmal mit dem Logic-Analyzer wenn ich seine Auflösung sehr gering einstelle, sodass er die einzelnen Zwischenimpulse garnicht erkennt. Die 17 Bit Preambel sind wohl eindeutig und fix und dienen dazu das sich der Empfänger auf den Takt synchronisieren kann. Das dann folgende Signal sind dann schon die Nutzdaten.
:
Bearbeitet durch User
Olli Z. schrieb: > > Da es am PIC also ein bereits moduliertes Signal gibt kann mein Siglent > leider keinen Manchester-Decode durchführen, oder ich habe die richtige > Einstellung dazu noch nicht gefunden. Das kann man doch auch ohne Dekoder machen, ich habe damals vor drei Jahren "EL-50449_singleframe.PNG" von weiter oben genommen (ich nehme an das hier ist immer noch der EL-50449), siehe das Bild im Anhang mit dem manuell eingezeichneten Takt. Zuerst das Preamble, dann grün die Bits des Sync-Byte (da werden auch ungültige Manchester-Codes wie "11" und "00" verwendet), dann kommen vier Bytes Daten (Manchester Code, jeweils mit einer schwarzen Linie getrennt). Da sieht dann so aus:
1 | // Sync |
2 | |
3 | 1,1, 1,0, 0,0, 1,0, 1,1, 0,0, 1,1, 0,0, 1,0, |
4 | |
5 | // Data (4 Bytes) |
6 | |
7 | 1,0, 0,1, 1,0, 0,1, 0,1, 1,0, 0,1, 1,0, // 0x5A |
8 | 1,0, 0,1, 1,0, 0,1, 0,1, 1,0, 0,1, 1,0, // 0x5A |
9 | 0,1, 1,0, 0,1, 1,0, 0,1, 1,0, 0,1, 0,1, // 0xAB |
10 | 0,1, 1,0, 0,1, 1,0, 0,1, 1,0, 0,1, 1,0 // 0xAA |
Wie gesagt, das ist drei Jahre her, ich habe das jetzt nicht mit den Bildern vom Oszilloskop verglichen. Wenn man die Sequenz selber sendet (z.B. mit einem etwas modifzierten TPMS Tool) dann funktioniert das auch (hat es zumindest damals vor drei Jahren).
Hm, woran kann die Phasenverschiebung liegen? Neben Auflösungsabweichung in der Grafik. Ich habe die roten Taktstriche immer im gleichen Abstand gezeichnet und dann im Block durch Gruppenskalierung so angepasst das es im SYNC stimmt. Auch in Deiner Grafik ist das nicht richtig taktsynchron. Gibt es da noch eine zusätzliche Pause?
:
Bearbeitet durch User
Olli Z. schrieb: > > Auch in Deiner Grafik ist das nicht richtig taktsynchron. Gibt es da > noch eine zusätzliche Pause? Das steht da ja schon dass ich den Takt manuell eingezeichnet habe. Und, wie schon geschrieben, wenn ich das mit eigenem Code schicke funktioniert es (auch mit anderen Sequenzen bei anderen TPMS Sensoren). Ich habe aber nicht vor mich jetzt nach drei Jahren erneut im Detail damit zu beschäftigen.
Alls gut Dieter, musst Du auch nicht. Dann eben mal nur für mich bzw. andere die das evtl. noch interessiert. Ich habe mir mal die Mühe gemacht und etwas länger hingeschaut und mit dem Datenblatt verglichen. Mein Denkfehler war das der Takt aufgrund der Manchester-Kodierung etwas verschoben aussieht. Ich habe dann mal das SYNC-Pattern aus dem Datenblatt über mein Datagramm skaliert (graue Balken) und es passt perfekt! Das ist also ein statisches Pattern und enthält eigentlich illegale Manchester-Codes. Danach folgt dann die im Datenblatt angegebene 16-Bit Wakeup-ID, wie Dieter schon richtig schrieb: 0x5A, 0x5A. Nun folgen laut Datenblatt beliebig viele Datenbytes, im Fall der Ford-Sensoren sind es wohl nur zwei, nämlich 0xAB, 0xAA. Zum manuellen dekodieren des Manchester-Bitfolge habe ich diesen Online-Dekoder verwendet: https://eleif.net/manchester.html Auf Github gibt es ein Projekt für den RTL-Chip zum dekodieren von Funksignalen. Dort hat sogar mal jemand das für die Ford-Sensoren eingebracht: https://github.com/merbanan/rtl_433/blob/master/src/devices/tpms_ford.c Wenn man also einen Versuchsaufbau nahe eines Rades (habe ja immer einen Satz im Keller ;-) macht, müsste man, nachdem die richtige LF-Signalfolge gesendet wurde, entsprechende Antworten von den Radsensoren über 443 MHz erhalten. Mein Problem ist ja auch das es bei mir nicht klappt, d.H. das genannte Trigger-Tool scheinbar keine Sendung der Radsensoren initiiert. Ich habe inzwischen ein anderes BCM für meinen Mondeo gekauft, welches die Ansteuerung der RDKS-Initiator-Antennen beherrscht (mein aktuelles kann das nicht). Dieses werde ich irgendwann mal tauschen da ich es auf dem Schreibtisch nicht ohne weiteres in Funktion bringen kann, zumindest nicht so das es glaubt das Fahrzeug wäre startbereit und löst die Sendung aus. Sobald das im Auto ist und funktioniert (Antennen sind bereits verbaut) werde ich das Ausgangssignal mit dem DSO capturen und mit der Sendefolge hier vergleichen. Meine Vermutung ist das diese anders sein wird, andere Wakeup-ID, andere Nutzdaten-Bytes. Mit der richtigen Folge könnte ich dann das Programm des Tools korrigieren. Für mich persönlich dann zwar nutzlos, aber für andere die das gleiche haben wie ich gerade ("Schmalspur"-RDKS) vermutlich sehr hilfreich. In jedem Fall ein cooles Projekt :-) Also werde ich mich als nächstes mal mit dem MPLAB beschäftigen und wie ich damit ein Programm für den PIC12F508 erstelle welches die Aussendung vornimmt. An das aktuelle komme ich ja leider wegen dem gesetzten Copy-Protection-Fuse nicht ran.
Olli Z. schrieb: > > Mein Problem ist ja auch das es bei mir nicht klappt, d.H. das genannte > Trigger-Tool scheinbar keine Sendung der Radsensoren initiiert. Welche Sensoren sind es denn genau? > Meine Vermutung ist das diese anders sein wird, andere Wakeup-ID, andere > Nutzdaten-Bytes. Mit der richtigen Folge könnte ich dann das Programm > des Tools korrigieren. Es gibt eine ganze Menge unterschiedlicher Aktivierungssequenzen, je nach Hersteller. Und auch die Baudrate kann sich unterscheiden. > Also werde ich mich als nächstes mal mit dem MPLAB beschäftigen und wie > ich damit ein Programm für den PIC12F508 erstelle welches die Aussendung > vornimmt. Wenn Du den PIC entfernst kannst Du jeden beliebigen Mikrocontroller nehmen. Alternativ den relativ günstigen EL-50448 modifizieren (das ist der mit 125 kHz Daueraussendung), den kann man leicht so umbauen dass man das Signal modulieren kann. Die Frage ist was das bringen soll wenn Du die Sequenz für Deine Sensoren nicht kennst. Brute-Force kann sehr lange dauern.
Olli Z. schrieb: > Auf Github gibt es ein Projekt für den RTL-Chip zum dekodieren von > Funksignalen. Dort hat sogar mal jemand das für die Ford-Sensoren > eingebracht: > https://github.com/merbanan/rtl_433/blob/master/src/devices/tpms_ford.c Die Frage ist nur, für welche Sensoren, die sind nicht bei allen gleich. > Mein Problem ist ja auch das es bei mir nicht klappt, d.H. das genannte > Trigger-Tool scheinbar keine Sendung der Radsensoren initiiert. Ich habe > inzwischen ein anderes BCM für meinen Mondeo gekauft, welches die > Ansteuerung der RDKS-Initiator-Antennen beherrscht Mondeo welcher? Meines Wissens musste beim mk4 nichts angelernt werden, der hatte in jedem Radhaus sein Antennchen. Im Bordcomputer konnte man sich die Luftdrücke anschauen, auch korrekt, nachdem man vorne - hinten vertauscht montiert hat. Im mk5-forum wurde geschrieben, dass dieser keine Einzelwerte zeigen kann und andere Sensoren habe. Das haben sie wieder umgebastelt, in einer neuren Reihe mk5 werden die wieder angezeigt. Ich habe meinen mk5 Februar 2018 bekommen, der Händler hatte Winterreifen als Ford-Komplettrad montiert. Zum Sommer habe ich umgeschraubt, da musste garnichts angelernt werden, das funktionierte einfach. Ich hatte neulich eine Warnung, HR zu wenig Druck (Nagel drin). Original saß das Rad vorne rechts, trotzdem wurde die korrekte Position gezeigt. Für mich ist unklar, ob und/oder wann man den Anlernsender überhaupt benötigt. Wenn nicht: Sobald sich der Druck ändert, senden die Sensoren. Ich denke mal, wenn Du 0,2 bar ablässt, meldet der sich auch ohne Anlernsender.
Dieter S. schrieb: > Welche Sensoren sind es denn genau? Im MK4 kommen VDO S180084730Z (Sensor-ID muss mit "0" beginnen!) zum Einsatz. > Wenn Du den PIC entfernst kannst Du jeden beliebigen Mikrocontroller > nehmen. Alternativ den relativ günstigen EL-50448 modifizieren (das ist > der mit 125 kHz Daueraussendung), den kann man leicht so umbauen dass > man das Signal modulieren kann. Ich würde einfach den nehmen den ich habe, da ist doch auch alles drin, außer das ich das Signal selbst per Software modulieren muss. Wenn die Chinesen das geschafft haben... Ich kann zum einen den vorhandenen PIC umprogrammieren, zum anderen habe ich mir bereits welche zum basteln gekauft. > Die Frage ist was das bringen soll wenn Du die Sequenz für Deine > Sensoren nicht kennst. Brute-Force kann sehr lange dauern. Ja, das habe ich ja geschrieben. Demnächst werde ich mir ein anderes BCM einbauen das diese Sequenz an Antennen in den Radkästen sendet. Es gibt aber eine ganze Reihe von Leuten die, wie ich bis dato, sowas nicht haben und trotzdem RDSK nutzen. Das geht mit einem kleinen Trick auch mit BCMs die keine Antennensteuerung besitzen. Und dafür ist dieses Trigger-Tool sehr hilfreich. Diese könnten dann einfach ihr Tool umprogrammieren sodass es wirklich für Ford Mondeo MK4 funktioniert. ICH hätte mich sehr gefreut wenn sich mal jemand die Mühe gemacht hätte. Aber wie heißt es so schön in dem Lied? "Und was es nicht gibt musst Du erfinden"...
Olli Z. schrieb: > Im MK4 kommen VDO S180084730Z (Sensor-ID muss mit "0" beginnen!) zum > Einsatz. Bild: Ford-Winterrad November 2003.
Hier ist die Sequenz für den VDO/Continental TPMS Sensor S180052020 bzw. mit der anderen Bezeichnung S180084730Z. Zu den Bezeichnungen der VDO/Continental TPMS Sensoren und die dazugehörigen Fahrzeuge siehe hier: https://www.vdo.com/media/182593/2017-02_tpms-oe-sensors_application-list.pdf Die Sequenz ist:
1 | // Sync (wie schon weiter oben) |
2 | |
3 | 1,1, 1,0, 0,0, 1,0, 1,1, 0,0, 1,1, 0,0, 1,0 |
4 | |
5 | // Manchester codierte Daten |
6 | |
7 | 0x61, 0x5E, 0x13, 0xC6, 0x6C, 0x39 |
Die aktuelle Platine des EL-50449 sieht anders aus, siehe das Bild im Anhang. Die Bezeichnung des IC ist abgeschliffen, ob das immer noch ein PIC ist müsste man prüfen. Der Mikrocontroller steuert auch die rote LED für "Low Bat" an, die LED Verbindungen sind teilweise im Bild eingezeichnet.
Ich versuche mich gerade am Code für den PIC12F508 und habe mir dazu ein paar Lektionen für den MPLAB-X IDE reingezogen. Eine blinkende LED habe ich zumindest schonmal hin bekommen (haha)
1 | void main(void) { |
2 | OPTION = 0b11011111; // Clear T0CS on using GP2 as output |
3 | TRIS = 0b111010; // 0x3A GP0 and GP2 as output |
4 | GPIO = 0b00000000; |
5 | while(1) { |
6 | __delay_ms(250); |
7 | GPIO = 0b00000100; // 0x04 GP2 HIGH, GP0 LOW |
8 | __delay_ms(250); |
9 | GPIO = 0b00000000; |
10 | } |
11 | } |
Für das Datagram brauche ich eine Senderoutine - 17 Bits ("1") Sync - die Preamble (teils ungültige Manchester codes, also speziell) - die ID und Trigger-Bytes (normales Manchester) Ich überlege das in C zu machen, ggf. mit etwas Inline-Assembler für die zeitkritischen Dinge. Mir geht es erstmal stur um die Senderoutine. Den Auslöser (Taster-Erkennung samt Entprellung) die Stromspareinstellung etc. im Nachgang. Eine Manchester-Codierung habe ich in einem OpenSource-Projekt gefunden, welches jedoch für einen größeren PIC gemacht wurde:
1 | /* |
2 | Author Martin Lints lintsmartin@gmail.com on 2016 |
3 | Do whatever you want with this software, don't blame me for anything you do. |
4 | */ |
5 | |
6 | #include "manchester_tx.h" |
7 | |
8 | #define TWAIT 215 // put 850 us into timer, 860/4 = 215, 255-215 = 40 (PRESC. 4) |
9 | |
10 | /* initial setup of special function registers */ |
11 | void setup(void) |
12 | { |
13 | /* Option_reg*/ |
14 | OPTION_REG = 0x11; /* GPIO en, gp2 int on fall, t0clocksource intern., incr hi-lo , prescal to tmr, prescale 1:4 */ |
15 | |
16 | /* setup interrupts */ |
17 | INTCON = 0xc8; // GIE 1, PEIE 1, T0IE 0, INTE (GP2) 0, GPIE 1 (vaja), T0IF 0 (miks mitte), INTF 0, GPIF 0 |
18 | //GIE = 0; |
19 | |
20 | /* Calibrate osc*/ |
21 | |
22 | __asm |
23 | bsf STATUS, 5 |
24 | call 3FFh |
25 | movwf OSCCAL |
26 | bcf STATUS, 5 |
27 | __endasm; |
28 | |
29 | /* ANSEL off (analog select register)*/ |
30 | ANSEL = 0x00; // all analog inputs (last nibble) |
31 | |
32 | /* CMCON off */ |
33 | CMCON = 0x07; // comparator off |
34 | |
35 | /* set TXPIN to output*/ |
36 | TXTRI = 0; |
37 | } |
38 | |
39 | /* Wait for half period of the Manchester |
40 | */ |
41 | void waitT2(void) |
42 | { |
43 | TMR0 = 0; |
44 | while (TMR0 < TWAIT) {} |
45 | /* |
46 | TMR0 = TWAIT; // initialize timer value |
47 | T0IF = 0; // clear previous overflows |
48 | // now wait |
49 | while (!T0IF) {} |
50 | */ |
51 | } |
52 | |
53 | /* send lo-hi as bit 1 */ |
54 | /* turn on TXPIN for Manchester half period */ |
55 | /* trying without modulation and with timer */ |
56 | /* aiming at ~ 850 us */ |
57 | /* REMEMBER TO SET TXPIN TO 0 AFTER SENDING! */ |
58 | void send1(void) |
59 | { |
60 | TXPIN = 0; |
61 | waitT2(); |
62 | __asm |
63 | nop |
64 | nop |
65 | nop |
66 | nop |
67 | __endasm; |
68 | TXPIN = 1; |
69 | waitT2(); |
70 | } |
71 | |
72 | /* send hi-lo as bit 0 */ |
73 | /* turn off TXPIN for Manchester half period */ |
74 | /* aiming at ~ 850 us */ |
75 | /* REMEMBER TO SET TXPIN TO 0 AFTER SENDING! */ |
76 | void send0(void) |
77 | { |
78 | TXPIN = 1; |
79 | waitT2(); |
80 | __asm |
81 | goto $+1 |
82 | goto $+1 |
83 | __endasm; |
84 | TXPIN = 0; |
85 | waitT2(); |
86 | } |
87 | |
88 | void sendbyte(unsigned char datau) |
89 | { |
90 | unsigned char j; |
91 | unsigned char mask = 0x80 ; // starting at 1000 0000 |
92 | for (j=0; j<8; j++) { |
93 | if (datau&mask) // send 1 |
94 | { |
95 | send1(); |
96 | } else { |
97 | send0(); |
98 | } |
99 | mask >>= 1; // shift mask right one bit |
100 | } |
101 | TXPIN = 0; // reset TXPIN to 0 in case last was send0 |
102 | } |
103 | |
104 | void delay_ms(unsigned char ms) |
105 | { |
106 | unsigned char u; |
107 | while (ms--) { |
108 | /* Inner loop takes about 10 cycles per iteration + 4 cycles setup*/ |
109 | for (u=0; u < 100; u++) { |
110 | __asm nop __endasm; |
111 | } |
112 | } |
113 | } |
:
Bearbeitet durch User
Das TPMS-Tool verwendet den GP0 für eine Art Selbsthaltung. Der Taster führt 3,3V an + vom PIC, dieser startet und zieht als erstes den Ausgang GP0 hoch. Der wiederum speist über einen Transistor ebenfalls die Stromversorgung vom PIC. Dadurch läuft das Programm einmal durch und am Ende wird GP0 wieder auf 0 gezogen und somit schaltet sich der PIC selbst ab. Leider kann man den PIC in dem TPMS-Tool nicht Inline-Programmieren, daher habe ich mir einen externen Sockel angebaut und programmiere den Chip separat. An GP2 ist die Kathode der grünen LED über einen 220 Ohm Widerstand angeschlossen. Zieht man den IO auf 0 leuchtet diese. Ein erster "Blinky" in C war erfolgreich. Mein erster Timing-Versuch in C war so, la la. Ich habe einfach mal den GP2 ohne Verzögerung von 1 auf 0 geschaltet in einer Endlosschleife. Das bringt max. 246 kHz (4µs) und leider kein PPV von 50%.
Weil das Timing kritisch ist (ich benötige am Antennen-Ausgang ja recht präzise 125 kHz) habe ich es erstmal mit Inline-Assembler gemacht:
1 | void main(void) |
2 | { |
3 | PON = 1; // turn on permanent power |
4 | OPTION = 0b11001111; |
5 | TRIS = 0b00001000; |
6 | while(1) { |
7 | asm("bcf GPIO, 2"); // ON |
8 | asm("nop\nnop\nnop"); |
9 | asm("bsf GPIO, 2"); // OFF |
10 | asm("nop"); |
11 | } |
12 | } |
Der PIC im TPMS-Tool wird mit einem 4 MHz Quarz-Oszillator betrieben. Im CONFIG-Byte steht daher "XT" als Quelle. Bei 4 MHz müsste jeder Programmcycle 250ns lang sein. Für eine Frequenz von 125 kHz am IO-Pin ist eine Periode von 8µs erforderlich. Bei einem Puls-Pausen-Verhältnis von 1:1 also 4µs pro Phase, was wiederum 16 Programmzyklen entspricht. Ein Bit-Set/Clear für den IO dauert laut Datenblatt 1 CYCLE, ebenso ein NOP. Beim IO wird NACH dem Zyklus der Pin eingestellt. Ein GOTO dauert 2 Zyklen. Entweder kann ich also nicht rechnen oder irgendwas mache ich noch falsch, denn ich habe ja im obigen Code nur ein viertel der eigentlich benötigten Zyklen, also 4 anstelle 16.
Olli Z. schrieb: > > Entweder kann ich also nicht rechnen oder irgendwas mache ich noch > falsch, denn ich habe ja im obigen Code nur ein viertel der eigentlich > benötigten Zyklen, also 4 anstelle 16. Bereits ganz am Anfang des Datenblatt steht:
1 | - DC – 4 MHz clock input |
2 | - DC – 1000 ns instruction cycle |
Und weiter hinten dann: "The clock input (OSC1/CLKIN pin) is internally divided by four to generate four non-overlapping quadrature clocks, namely Q1, Q2, Q3 and Q4."
Danke Dieter, das erklärt meinen Fehler (Sorry das hätte ich auch selbst finden können, stöhn) Das der Ausgangstakt selbst mit Assemblercode (habe im MPLAB das Disassembly angeschaut, stimmt) nicht präzise ist liegt dann an was? Laut DSO ist die Periode minimal zu lang (8,07µs anstelle 8,00µs) wodurch die Frequenz etwas abweicht. Wie haben es die Chinesen geschafft hier mit den gleichen Betriebsmitteln präzise 125 kHz hin zu bekommen? Das Calibration-Value im Chip beeinflußt ja nur den internen Oszillator. Somit hängt dann wohl die Präzision nur an der externen Taktquelle? Ich werde es wohl testen müssen ob die Abweichung stört... auch muss ich noch das PPV von 1:7 einbauen, im Originalcode wurde ja 1µs gesendet und dann 7µs Pause gemacht. Wenn ich jetzt die Funktionen zum senden den Symbole implementiere (siehe Beitrag "Re: Funktion Reifendruckanlerngerät EL-50448; OEC-T5; Welches Bauelement ist das?") muss ich ja z.B. 16 0/1-Signale senden, gefolgt von einer 134µs Pause. Ich werde also wohl eine Funktion schreiben die die Anzahl der Takte erhält und diese sendet, sowie eine für eine Pause in einer bestimmten Länge. Die Herausforderung wird sein die konditionellen Befehle drumherum in die Zeiten mit einzukalkulieren sonst erhalte ich ja eine Phasenverschiebung im Ausgangssignal. Möglicherweise toleriert das der Empfänger nicht.
:
Bearbeitet durch User
Bitte 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.