Forum: Fahrzeugelektronik Identifizierung Signal "Tür offen"


von P. K. (knauer)


Lesenswert?

Hallo,

wir haben ein Wohnmobil auf Citroen-Jumper-Basis, Ezl. 2013. Dort ist 
ein sogenannter "Transformatorstecker" an der rechten B-Säule eingebaut, 
dafür gedacht, dem Aufbauhersteller eine einfache Schnittstelle zum 
Basisfahrzeug zu bieten. Dort ist auch ein Pin geführt, der in der 
Servicedokumentation mit "Information Tür offen" bezeichnet ist.

Dieser Pin führt ein digitales Signal - Low: 0 VDC, High: ~12 VDC

Es gibt zwei Zustände, die sich durch verschiedene Signalverläufe 
unterscheiden:
Zustand 1: alle 75 ms (13,33 Hz) für ~0,5 ms High, sonst Low
Zustand 2: alle 5 ms (200 Hz) für ~0,9 ms High, sonst Low

Er nimmt unter folgenden Bedingungen diese Zustände ein:
a) beide Türen geschlossen: Zustand 1, aber alle 10 s bis 60 s 
(scheinbar unregelmäßig) für genau 1 s oder genau 2 s (auch scheinbar 
unregelmäßig) Zustand 2
b) min. eine Tür offen und bis ca. 10 s bis 30 s (scheinbar 
unregelmäßig) nach dem Schließen: Zustand 2

Kann jemand dieses Signal erklären? Gibt es dafür eine Spezifikation?
Wird mir durch die unmotivierten Zustandswechsel (siehe a) irgendetwas 
mitgeteilt, was ich auswerten könnte? Ist das irgend ein Standard-Signal 
oder fahrzeugspezifisch?

(Hintergrund: Ich will das Tür-Offen-Signal an dem Digitaleingang meines 
LTE-Routers nutzen, um eine Alarm-SMS zu senden. Aber das unregelmäßige 
Schalten auf Zustand 2 während die Tür eigentlich zu ist, vermiest mir 
das etwas.)

Danke Euch schonmal!

von Andrew T. (marsufant)


Lesenswert?

P. K. schrieb:
> (Hintergrund: Ich will das Tür-Offen-Signal an dem Digitaleingang meines
> LTE-Routers nutzen, um eine Alarm-SMS zu senden. Aber das unregelmäßige
> Schalten auf Zustand 2 während die Tür eigentlich zu ist, vermiest mir
> das etwas.)

Versuch es mal mit "umgekehrtem Denken". soll heißen:

Werte stattdessen einfach das AUSBLEIBEN des Signal 1 aus. Bleibt dieses 
Signal aus, ist wohl eine Tür offen - und zur Validierung prüft deine 
Zusatzschaltung ob das n-mal hintereinander ist (== Ausblenden von 
Zufallsfehlers)  z.B. n=3 : spätestens nach 225ms hast du eine solide 
Auswertung des "Tür auf" Zustandes

von aggressive (Gast)


Lesenswert?

P. K. schrieb:
> Tür-Offen-Signal... Alarm
Möglicherweise liesse sich die Innenbeleuchtung einfacher auswerten.

von P. K. (knauer)


Lesenswert?

Danke für die Hinweise.
Also, ein anderes Signal zu finden wäre kein Problem. Will ich aber 
nicht, ich hab ja dieses. :) Da brauche ich keine neuen Kabel ziehen. 
Und wenn es sogar noch irgend eine andere Information mitliefert, umso 
besser.

Zur Auswertung des Signals: ich verstehe nicht,  da du meinst, Andrew. 
Mir ist der Workaround bewusst, das ich, wenn Zustand 2 kommt, 2 
Sekunden abwarten kann, ob er wieder zu Zustand 1 zurückgeht. Wenn 
nicht, ist die Tür wirklich offen. (2 Sekunden sind aber auch viel.)
Wie du das aber schon nach 225 ms erkennen möchtest, ist mir unklar. Ich 
glaube, das geht schlichtweg nicht. Denn innerhalb der ersten jeweils 1 
oder 2 Sekunden unterscheidet sich der unmotivierte Zustand 2 nicht vom 
echten "Tür auf"-Zustand 2.

Die Zustände in "high" und "Low" wandeln mache ich derzeit mit einem 
einfachen rc-Glied. Da habe ich den Zustandswechsel nach <0,2 s 
detektiert. Ich glaube, das hast du mit Zustandswechsel gemeint. Da muss 
ich nicht Impulse zählen oder deren Länge messen.

Aber es geht nicht um die Unterscheidung der Zustände 1 oder 2, sondern 
um die Unterscheidung Tür offen oder zu, also - nennen wir es Modus - a) 
oder b). Lies nochmal nach oben...

Aber vor allem bleibt die Frage: welche Information steckt 
möglicherweise in den unmotivierten Zustandswechseln während Modus a)?

von Thomas (kosmos)


Lesenswert?

da alles nur Vermutungen sind, fahr zu Zitröen schnapp dir den Meister 
gibt im etwas Hartgeld in die Hand und frag in freundlich ob er dir dazu 
etwas raussuchen kann. Vielleicht erfährst du wofür das Signal noch 
verwendet wird.

Wenn du Pech hast dann kennt nichtmal die Werkstatt diese Details und 
wissen nur wir man das Teil austauscht.

von Wolfgang (Gast)


Lesenswert?

P. K. schrieb:
> Denn innerhalb der ersten jeweils 1
> oder 2 Sekunden unterscheidet sich der unmotivierte Zustand 2 nicht vom
> echten "Tür auf"-Zustand 2.

Zustand 1 tritt nach deiner Beschreibung nur auf, wenn die Tür wirklich 
zu ist. Falls dieses Signal ausbleibt, kann es also nur daran liegen, 
dass die Tür offen ist.

von P. K. (knauer)


Lesenswert?

Wolfgang schrieb:
> Zustand 1 tritt nach deiner Beschreibung nur auf, wenn die Tür wirklich
> zu ist.

Lies nochmal nach im Ausgangsposting, unter Modus a) - Tür offen. Dort 
ist der unmotivierte Wechsel von Zustand 1 auf Zustand 2 beschrieben 
(hinter dem ich eine Information vermute). Zustand 1 gibt es nur bei Tür 
geschlossen, richtig. Aber bei geschlossener Tür gibt es nicht nur 
Zustand 1. Er bleibt auch bei geschlossener Tür ab und zu aus.

> Falls dieses Signal ausbleibt, kann es also nur daran liegen,
> dass die Tür offen ist.

... ist also ein Trugschluss.

Thema Werkstatt: sehe ich kaum Chancen. Denn wie erwähnt, habe ich 
Zugriff auf die Servicedokumentation. Mehr haben Werkstätten m.W. auch 
nicht. Ich werde noch den Citroen-Support anmailen, falls es sowas gibt. 
Und vielleicht auch einen Aufbauhersteller.
Aber das tut ja alles nichts zur Sache.

Übrigens sind Vermutungen die Essenz von Reverse Engineering. Ohne 
geht's nicht.

Ich habe noch Hoffnung: hat jemand hier noch sachliche Ideen zu dem 
Signal?
Kann ja sein, dass jemandem solch ein Signal schonmal begegnet ist und 
er eine andere Doku hat (z.B. anderer Fahrzeughersteller oder eine Norm) 
oder es reverse engineered hat.
Wenn mein Logger fertig ist, werde ich auch mal schauen, ob ich 
irgendeine Regelmäßigkeit in den Zustandswechseln während Modus a) finde 
und das ggf. hier posten.

Danke euch schonmal!

von Mathias A. (mrdelphi)


Lesenswert?

P. K. schrieb:
> Es gibt zwei Zustände, die sich durch verschiedene Signalverläufe
> unterscheiden:
> Zustand 1: alle 75 ms (13,33 Hz) für ~0,5 ms High, sonst Low
> Zustand 2: alle 5 ms (200 Hz) für ~0,9 ms High, sonst Low

Spontaner Gedanke: Theoretisch könnte es auch ein digitales serielles 
Signal sein -- mit z.B. 2 kBit/s wäre dann im Zustand 1 jeweils 1 Bit 
gleich 1 und im Zustand 2 jeweils 2 Bit.

Ein UART mit 1 Startbit/kein Parity würde sowas beispielsweise erzeugen, 
wenn das erste übertragene Datenbit im Zustand 1 gleich 0 und im Zustand 
2 gleich 1 ist (und alle anderen Bits immer gleich Null sind)

Nachtrag: wie schnell hast Du das Signal beim messen abgetastet -- 
womöglich hat es eine weit höhere Bitrate und man sieht hier nur Bytes 
oder Datenpakete?

: Bearbeitet durch User
von Ralf X. (ralf0815)


Lesenswert?

P. K. schrieb:
> Wolfgang schrieb:
>> Zustand 1 tritt nach deiner Beschreibung nur auf, wenn die Tür wirklich
>> zu ist.
>
> Lies nochmal nach im Ausgangsposting, unter Modus a) - Tür offen. Dort
> ist der unmotivierte Wechsel von Zustand 1 auf Zustand 2 beschrieben
> (hinter dem ich eine Information vermute). Zustand 1 gibt es nur bei Tür
> geschlossen, richtig. Aber bei geschlossener Tür gibt es nicht nur
> Zustand 1. Er bleibt auch bei geschlossener Tür ab und zu aus.
>
>> Falls dieses Signal ausbleibt, kann es also nur daran liegen,
>> dass die Tür offen ist.
>
> ... ist also ein Trugschluss.
>
> Thema Werkstatt: sehe ich kaum Chancen. Denn wie erwähnt, habe ich
> Zugriff auf die Servicedokumentation. Mehr haben Werkstätten m.W. auch
> nicht. Ich werde noch den Citroen-Support anmailen, falls es sowas gibt.
> Und vielleicht auch einen Aufbauhersteller.
> Aber das tut ja alles nichts zur Sache.
>
> Übrigens sind Vermutungen die Essenz von Reverse Engineering. Ohne
> geht's nicht.

> Ich habe noch Hoffnung: hat jemand hier noch sachliche Ideen zu dem
> Signal?
> Kann ja sein, dass jemandem solch ein Signal schonmal begegnet ist und
> er eine andere Doku hat (z.B. anderer Fahrzeughersteller oder eine Norm)
> oder es reverse engineered hat.
> Wenn mein Logger fertig ist, werde ich auch mal schauen, ob ich
> irgendeine Regelmäßigkeit in den Zustandswechseln während Modus a) finde
> und das ggf. hier posten.
>
> Danke euch schonmal!

Ich verstehe Deine Überlegungen nicht, falls meine Vermutung richtigt 
ist, dass Du nicht völlig auf den Kopf gefallen bist und Du selber auch 
schon umfangreich gegoogelt hast.

In tausenden Foren existieren ggf. millionen Threads, wo es um das 
Auslesen und Verstehen proprietärer SW geht.
Es finden sich auch jede Menge (erflolglose!) Threads, wo es um die 
PSA-SW geht, auch um die Signale der PSA-Transporter, auch an der 
optionalen Buchse an der B-Säule.
Ich nehme an, Du nimmst das Türzustands-Signal an Pin 6 der 15-poligen 
Buchse ab?

Hat Dein Jumper WoMo noch mehr Türen als die "beiden Türen" vorne?
Wenn ja, wird auch deren Zustand über das Signal signalisiert?
Wenn letzteres nicht, wäre es ziemlich dumm, das Signal für eine 
Alarmanlage zu nutzen.
Ansonsten, im Eingnsposting nur von den "beiden Türen" zu schreiben.

Viele Kfz-Systeme zeigen im Kombiinstrument an, welche(!) Tür nicht 
richtig geschlossen ist.
Dabei bekommt der µC des Kombiinstruments diese Info natürlich über ein 
codiertes Signal einer proprietären SW eines anderen Steuergerätes.

Für eine unregelmässige Übermittlung der Daten gibt es viele Gründe.
Der simpelste Grund ist, dass der Prozessor auch noch andere Prozesse 
abarbeiten muss, die unterschiedlich lange dauern.
Bei z.B. Alarmanlagen erreicht man damit ggf. auch eine höhere 
Sicherheitsstufe.

Selbst wenn jemand die ggf. auch noch fahrzeugspezifische SW des 
PSA-Konzern ausgelesen hat, soll er diese hier einstellen?
Und worauf möchtest Du diese adaptieren, um dann ein Signal zu erzeugen, 
das Dein "Router" versteht?

Sicherheitstechnisch wäre Deine Massnahme in meinen Augen als Alleinige 
eh absoluter Humbug, wobei es natürlich auch auf die Umstände ankommt.
WENN Du aber eh andere und wichtigere Massnahmen gegen 
Einbruch/Diebstahl installierst, ist es noch mehr Humbug, die Auswertung 
des Türzustandssignal zu nehmen, weil es "nun einmal schon da ist".

von Philip S. (phs)


Lesenswert?

Mathias A. schrieb:
> Nachtrag: wie schnell hast Du das Signal beim messen abgetastet --
> womöglich hat es eine weit höhere Bitrate und man sieht hier nur Bytes
> oder Datenpakete?

Daran habe ich auch beim Lesen als erstes gedacht.

Da Du explizit nach Vermutungen gefragt hast: Für den Automobilbau wäre 
es in meinen Augen eher ungewöhnlich, wenn ein spezielles Protokoll auf 
dem Physical Layer verwendet würde. Ich würde daher einen LIN Bus auf 
dem Pin vermuten.

von P. K. (knauer)


Lesenswert?

Hey,

vielen Dank für die Hinweise. Also, ich bin noch nicht dazu gekommen, 
einmal eine Langzeitaufzeichnung des Signals in Modus a) zu machen. Das 
wird vielleicht erhellend sein, wenn man die 1 Sekunde als 0 und die 2 
Sekunden als 1 loggt oder umgekehrt. Vielleicht zeigt sich irgendein 
Muster. Möglicherweise auch in den Abständen. Aber an Lin-Bus oder Uart 
glaube ich nicht so recht. Das wäre ja eine unterirdische Datenrate von 
ca. 0,03 Baud.

Wenn die Dauer der Zustand-2-Phasen (1 s oder 2 s) Bits darstellen, 
dauert ein Byte schon etwa 4 Minuten. Das ist noch deutlich langsamer 
als das DCF77-Signal (jetzt mal als Beispiel das langsamste Protokoll, 
das mir einfällt).
Wenn ich das so daherschreibe, kann ich mir eigentlich immer weniger 
vorstellen, dass da eine Datenübertragung stattfindet. Frage bliebe: 
warum dann solch ein Muster?

Mathias A. schrieb:
> Spontaner Gedanke: Theoretisch könnte es auch ein digitales serielles
> Signal sein -- mit z.B. 2 kBit/s wäre dann im Zustand 1 jeweils 1 Bit
> gleich 1 und im Zustand 2 jeweils 2 Bit.

Aber er macht dann in Zustand 1 sehr lange Pausen, nämlich 149 Bits 
lang.
In Zustand 2 wären es dann 2 Bits "1" und 8 Bits "0". Das passt für mich 
schon besser zu Uart als Zustand 1.
Aber es ist schon sehr verdächtig, dass Zustand 2 immer genau 1s oder 2 
s andauert. Das ist irgendwie nicht Uart. ;-)

> Nachtrag: wie schnell hast Du das Signal beim messen abgetastet --
> womöglich hat es eine weit höhere Bitrate und man sieht hier nur Bytes
> oder Datenpakete?

Ich habe (glaube ich) mit 100 MS/s abgetastet. Auf jeden Fall weit 
jenseits von gut und böse. Da kann m.M. nicht noch mehr in den Impulsen 
stecken als beschrieben.


Aber jetzt kommt das Schärfste: Mir ist gestern nach einem Hinweis in 
einem anderen Forum noch eine spezielle Service-Doku für 
Aufbauhersteller in die Hände gefallen, die ich noch nicht kannte, und 
da ist zu dem Signal noch ein Ticken mehr erklärt, nämlich: Das ist 
nicht als Ausgang gedacht, sondern als EINGANG! Über diesen meldet man 
gemäß dieser Doku umgekehrt dem Bordcomputer das Offensein der hinteren 
Aufbautüren!
Umso interessanter oder auch absurder ist es, dass trotzdem dort dieses 
beschriebene Signal anliegt, was sich zuverlässig beim Öffnen einer 
Kabinentür ändert (leider nicht ausschließlich dann). Kann das 
gleichzeitig ein Ein- und Ausgang sein?

Ralf X. schrieb:
> In tausenden Foren existieren ggf. millionen Threads, wo es um das
> Auslesen und Verstehen proprietärer SW geht.

Was interessiert mich die Software? Ich habe nach der Schnittstelle an 
diesem Pin gefragt. Du kennst den Unterschied!?
Auch properitäre Software kann mit nichtproperitären Protokollen nach 
außen kommunizieren. Interessant, wa? ;-)

Wenn deine Aussage ist: "die Schnittstelle ist properitär", dann mach 
diese Aussage doch einfach. Andere vermuten aber Linbus,  Philip sogar 
explizit nicht-properitär auf dem physical Layer. Kannst du ggf. 
begründen, warum du meinst, die Schnittstelle müsse properitär sein? 
Oder hast Du eine Idee, wie ich diese Vermutung verifizieren könnte?
Ein Indiz dafür ist ja, dass sie hier und in anderen Foren niemand 
kennt/deuten kann. Aber diese Information hat sich ja auch erst durch 
diesen Thread manifestiert.

> Es finden sich auch jede Menge (erflolglose!) Threads, wo es um die
> PSA-SW geht, auch um die Signale der PSA-Transporter, auch an der
> optionalen Buchse an der B-Säule.

Supi. Dann poste doch bitte einen dieser Links, die Du gefunden hast, wo 
es um das Thema dieses Signalverlaufes an Pin 6 geht. (Bitte nicht genau 
den Thread, den ich selbst dazu gepostet habe. ;-) )
Das ist irgendwie leider typisch in Foren, ein "google doch" oder "Steht 
doch überall." Wenn es das tut, und ich es übersehen habe, was glaubst 
Du, wäre wohl hilfreicher? Ein "Es findet sich jede Menge" oder ein 
"Schau mal, was ich dazu gefunden habe -> Link"?

> Ich nehme an, Du nimmst das Türzustands-Signal an Pin 6 der 15-poligen
> Buchse ab?

Jawohl, um Pin 6 geht es.

> Hat Dein Jumper WoMo noch mehr Türen als die "beiden Türen" vorne?

Ja, die Aufbautüren.

> Wenn ja, wird auch deren Zustand über das Signal signalisiert?

Nein.

> Wenn letzteres nicht, wäre es ziemlich dumm, das Signal für eine
> Alarmanlage zu nutzen.

Nein, wäre es nicht. Dumm wäre, NUR dieses Signal für die Alarmanlage zu 
benutzen. Aber die anderen Bestandteile der Alarmanlage oder 
Schaltkontakte an Aufbautüren, die ich vorsehe, spielen für die 
Fragestellung etwa die gleiche Rolle wie die Wagenfarbe. Deshalb habe 
ich diese Informationen auch nicht gepostet. Aber ehe Du fragst: weiß.

> Selbst wenn jemand die ggf. auch noch fahrzeugspezifische SW des
> PSA-Konzern ausgelesen hat, soll er diese hier einstellen?
> Und worauf möchtest Du diese adaptieren, um dann ein Signal zu erzeugen,
> das Dein "Router" versteht?

Mich interessiert die PSA-Software nicht die Bohne. Auf dem Router läuft 
meine eigene Software. Ich wüsste nur gern, was oder mit welchem (mglw. 
nicht properitärem) Protokoll mir an diesem Pin mitgeteilt wird.
Zuvorderst will ich ein Signal "Vordertür offen" an meinem Router 
nutzen, ohne neue Kabel ziehen zu müssen.
Die unmotivierten (jedenfalls nicht durch Türöffnen motivierten) 
Zustandswechsel in Modus a) sind erstmal reine Neugier. Sollten sie sich 
als informativ und interessant herausstellen, würde ich auch diese mit 
einer eigenen Software auswerten.

> WENN Du aber eh andere und wichtigere Massnahmen gegen
> Einbruch/Diebstahl installierst, ist es noch mehr Humbug, die Auswertung
> des Türzustandssignal zu nehmen, weil es "nun einmal schon da ist".

Warum soll das Humbug sein? Müsstest Du schon näher erklären, warum ein 
Signal, was vorhanden ist, nicht genutzt werden sollte. Und völlig 
unabhängig von weiteren Maßnahmen ist das grundsätzlich eine 
hochinteressante Information in der Objektüberwachung, ob eine Tür 
geöffnet wird.
Ich habe aber keine Lust, ausgerechnet mit Dir mein gesamtes Projekt 
durchzugehen. Bleiben wir doch einfach beim Thema: der Signalverlauf an 
diesem Pin.

: Bearbeitet durch User
von Mathias A. (mrdelphi)


Lesenswert?

P. K. schrieb:
> Das ist nicht als Ausgang gedacht, sondern als EINGANG! Über diesen
> meldet man gemäß dieser Doku umgekehrt dem Bordcomputer das Offensein
> der hinteren Aufbautüren!
> Umso interessanter oder auch absurder ist es, dass trotzdem dort dieses
> beschriebene Signal anliegt, was sich zuverlässig beim Öffnen einer
> Kabinentür ändert (leider nicht ausschließlich dann). Kann das
> gleichzeitig ein Ein- und Ausgang sein?

In der Tat eine interessante Info... kurze Frage erstmal noch: wie hast 
Du das Signal gemessen -- an der verbundenen Leitung, oder hast Du den 
Stecker getrennt und dann an der Leitung die zum Fahrzeug gehört 
gemessen?

von P. K. (knauer)


Lesenswert?

> In der Tat eine interessante Info... kurze Frage erstmal noch: wie hast
> Du das Signal gemessen -- an der verbundenen Leitung, oder hast Du den
> Stecker getrennt und dann an der Leitung die zum Fahrzeug gehört
> gemessen?

Letzteres. Also quasi am offenen Ausgang (oder eben Eingang) des 
Bordcomputers.

: Bearbeitet durch User
von P. K. (knauer)


Lesenswert?

Hey,

also, nochmal vielen Dank allen, die versucht haben zu helfen.
Ich gehe auch davon aus, dass das Signal schwerstens properitär ist. 
"Offiziell" ist es ja gar nicht da.
Da ich nun meine Pläne erweitert habe um eine Zentralverriegelung im 
Aufbau, möchte ich außerdem nun auch diesen Pin tatsächlich als Eingang 
in den Bordcomputer nutzen. Bietet mir die Möglichkeit einer 
Lichtsteuerung im Aufbau anhand der Türöffnung und eine Sperre gegen 
versehentliches Abschließen bei offener Tür.

Insofern können wir diesen Thread also als geschlossen betrachten. Was 
nicht heißt, dass nicht weitere Ideen einer Erklärung doch willkommen 
sind. Vielleicht haben andere ja auch mal Interesse.

Danke Euch, viele Grüße.

von P. K. (knauer)


Lesenswert?

So, ich bin nun mit diesem Projektteil so gut wie fertig.

Ich habe meine Aufbautüren mit Reedschaltern versehen, die beim Öffnen 
den besagten Pin 6 mit Masse verbinden. Soweit ist es vom Hersteller 
vorgesehen.

Zusätzlich werte ich das Signal an Pin 6 mittels eines ATTiny85 und 
untenstehendem Programm aus.
Wenn das Signal nicht pulst, ist es wohl auf Masse -> eine Aufbautür ist 
offen. Wenn es pulst, untersuche ich, ob der Zustand 2 länger als 2 
Sekunden andauert -> eine Vordertür ist offen. In Zustand 1 und den 
ersten 2 Sekunden von Zustand 2 wird davon ausgegangen, dass alle Türen 
zu sind.
Das Ergebnis gebe ich an einem Ausgangspin aus, der in den Router führt 
und dort eine Alarm-SMS auslöst.
Alles getestet, funktioniert soweit. Jetzt nur noch schön machen... :-)
1
#include <Arduino.h>
2
3
#define RXPIN 2 // input pin of signal in question
4
#define TXPIN 1 // output pin of evaluated signal
5
6
#define BLOCK_TIME 2000 // ms; time span to sit out the arbitrary signal changes
7
#define LOW_THRES 75000 // µs; timeout after which signal is considered permanent low (not pulsing)
8
#define WIDTH_THRES 700 // µs; threshold between pulse length of signal type 1 and signal type 2
9
10
#define BACKDOOR_OPEN 0      // state "one of the backdoors open"
11
#define DOORS_CLOSED 1       // state "all doors closed"
12
#define FRONTDOORS_UNCLEAR 2 // state "front doors open or arbitrary signal change"
13
14
void setup()
15
{
16
  pinMode(RXPIN, INPUT);
17
  pinMode(TXPIN, OUTPUT);
18
}
19
20
void loop()
21
{
22
23
  static unsigned long statetime = 0;
24
  static unsigned char currentstate = DOORS_CLOSED;
25
  unsigned char oldstate = currentstate;
26
27
  int pw = pulseIn(RXPIN, HIGH, LOW_THRES);
28
29
  if (pw == 0) // pulseIn timed out -> no pulse
30
    currentstate = BACKDOOR_OPEN;
31
  else if (pw < WIDTH_THRES) // pulse signal type 1
32
    currentstate = DOORS_CLOSED;
33
  else                              // pulse signal type 2
34
      if (oldstate == DOORS_CLOSED) // when closing the backdoors the car always goes from signal = 0 (BACKDOOR_OPEN) to signal type 2 (FRONTDOORS_UNCLEAR) for about 10 to 30 seconds. So we wait first until the car shows signal type 1 (DOORS_CLOSED) before we accept any change to signal type 2 as a candidate for "front door open"
35
  {
36
    currentstate = FRONTDOORS_UNCLEAR;
37
    statetime = millis();
38
  }
39
40
  if (currentstate == BACKDOOR_OPEN ||
41
      (currentstate == FRONTDOORS_UNCLEAR &&
42
       (unsigned long)(millis() - statetime) > BLOCK_TIME))
43
    digitalWrite(TXPIN, HIGH);
44
  else
45
    digitalWrite(TXPIN, LOW);
46
}

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
Noch kein Account? Hier anmelden.