Beiträge von Thomas77

    Hallo Olaf,

    Hä? Wie, aufgeben? ;(

    War nicht so ganz ernst gemeint. :)


    Ich hatte letzte Woche die Gelegenheit, mir ein Oszi auszuleihen und konnte sowohl die Versorgungsspannung als auch das Ausgangssignal des PIR genauer unter die Lupe nehmen.


    Ergebnis der Untersuchung: Wenn die CPU-Last erhöht wird, dann sind in der vom PiFace zur Verfügung gestellten Spannung eindeutig (periodisch wiederkehrende) Störungen erkennbar. D.h. nicht nur der plötzliche CPU-Lastwechsel ist problematisch, sondern allein eine höhere CPU-Last sorgt für (dauerhafte) Störungen in der Versorgungsspannung. Und diese Störungen führen wiederum zu den unerwünschten Auslösungen.


    Hier hatte ich Lösungsoptionen diskutiert. Letztlich konnte ich die Störungen in der Spannungsversorgung mit einer kleinen Schaltung (Kombination aus Kondensatoren und Zener-Diode) beseitigen, die zwischen PiFace und PIR geklemmt wurde. Seitdem konnte ich auch keine unerwünschten Auslösungen mehr beobachten.


    Viele Grüße,
    Thomas

    Hallo zusammen,


    vielen Dank erstmal für die Anregungen. Ich habe jetzt systematisch getestet und die Fehlerursache eingegrenzt, allerdings das Problem leider nicht lösen können.


    Alex: Ja, nach Abklemmen des PIR wurde der Event in Doorpi nicht mehr ausgelöst. Entsprechend ist jetzt sicher auszuschließen, dass es ein Software-Problem ist. Bzgl. Schaltplan: ja, stimmt, ich habe nur den relevanten Ausschnitt eingehängt, da ich das Problem nicht zwischen dem Ausgang der Schaltung und dem Eingang des Pi vermutet habe. Die Schaltung ist folgendermaßen mit dem Pi verbunden: MOV -> PiFace Eingang #2; VDD -> +5V PiFace; GND -> GND PiFace; alle anderen Anschlüsse spielen für das Problem keine Rolle.


    Mit meinen Tests habe ich folgendes herausgefunden. Gemessen/kontrolliert habe ich dabei jeweils die Spannung von VDD (Pin4), VREF (Pin1), TRG (Pin3) gegenüber GND (Pin2) am PIR mit einem digitalen Voltmeter (!) - ein Oszi stand mir nicht zur Verfügung - so dass Aussagen/Schlussfolgerungen, bei denen der zeitliche Verlauf der Spannung wichtig ist, mit Vorsicht zu genießen sind.


    1. Wenn ich meine Schaltung über eine separate Spannungsquelle betreibe und die Schaltung nicht mit dem Raspi verbunden ist, gibt es keine unerwünschte Auslösung des Ausgang TRG des PIR.


    => eine Störung durch Wärmestrahlung des Raspi ist somit ausgeschlossen


    2. Wenn ich meine Schaltung über den Raspi mit Strom versorge und kein weiterer Ein-/Ausgang meiner Schaltung mit dem Raspi verbunden ist, dann kommt es bereits zu unerwünschten Auslösungen des Ausgang TRG des PIR, sobald ich die CPU-Last erhöhe


    => es muss etwas damit zu tun haben, dass die Spannungsversorgung über den Raspi läuft


    Anmerkung: Ich konnte keine Schwankungen von VDD (Pin 4) und VREF (Pin1) feststellen, aber wie oben erwähnt, sagt das nichts, da ich das mit einem Voltmeter nicht feststellen kann, wenn die Schwankungen hinreichend kurz sind.


    3. Der Versuch, die Spannungsversorgung mit weiteren Kondensatoren (zunächst 100nF, dann 10µF) zu stabilisieren, brachten keinen Erfolg


    Ich weiß jetzt zwar, dass es irgendwie mit der Spannungsversorgung des Raspi zu tun haben muss, aber spätestens nach (3) bin ich wirklich ratlos. Vermutlich ist mein Problem dann besser in einem Elektronik-Forum aufgehoben. EDIT: Ich habe jetzt hier einen neuen Thread gestartet.
    Der Vollständigkeit halber: die Schaltung (d.h. der Timer LM555 und der Ausgang MOV meiner Schaltung funktionieren zuverlässig). Jede Auslösung des PIR führt zuverlässig dazu, dass der Ausgang MOV für die gewünschte Zeitdauer auf GND geschaltet wird.


    Vielleicht hat ja noch jemand eine Idee?


    Mir fällt nur noch (neben Aufgeben) ein, mir ein Oszi zu besorgen, um wirklich mal herauszufinden, was da mit der Versorgungsspannung nicht passt und wie stark die Amplitude am Ausgang TRG des PIR im unerwünschten Fall und im erwünschten Fall ist. Da hat Olaf oben schon recht. Wenn die Amplitude bei der unerwünschten Auslösung kleiner als bei der erwünschten Auslösung ist, aber trotzdem ausreicht, den LM555 zu triggern, dann kann ich mit einer kleinen Schaltung (Stichwort "Fensterkomparator") zwischen dem Ausgang TRG des PIR und dem Triggereingang des LM555 die Empfindlichkeit regeln.


    Viele Grüße,
    Thomas

    Hallo Olaf,


    ja, das ist wirklich wackelig. Ich werde wohl erst am Wochenende zu systematischen Tests kommen und dann hoffentlich die wirkliche Ursache finden.


    Der Bewegungsmelder ist folgendermaßen beschaltet:
    PIN1 = VREF = 2,5V (entspricht der Ansteuerung in der Referenzschaltung)


    Beim Experimentieren mit dem Bewegungsmelder habe ich "beobachtet", dass an PIN3 ebenfalls 2,5V (also VREF) anliegt, so lange keine Bewegung erkannt wird. Bei Bewegung scheint PIN3 für eine kurze Zeit zwischen 0V und 5V zu oszillieren.


    Im angeschlossenen Zustand ist PIN3 mit einem 10k Pull-Up Widerstand direkt mit dem Triggereingang des LM555 Timers verbunden. Laut Datenblatt löst der LM555 aus, wenn die Spannung am Triggereingang 1/3 VCC (bei mir ca. 1,7V) unterschreitet. Ich habe den relevanten Teil meines Schaltplans mal angehängt.


    Gut, dass wir darüber gesprochen haben. Jetzt sehe ich Eumel nämlich auch, dass in der o.g. Referenzschaltung zusätzlich noch ein 10nF Kondensator (C22) an PIN3 gegen GND geschaltet ist. Vielleicht ist das die Gegenmaßnahme gegen einen "übernervösen" Bewegungsmelder, die der Hersteller bereits vorgesehen hat. Zumindest ist es mal ein Anhaltspunkt.


    EDIT: Da es leicht auszuprobieren war, habe ich testweise einen 10nF Kondensator zwischen PIN3 und GND geklemmt. Leider wurde das Problem dadurch nicht gelöst. Ich teste weiter...


    Vielen Dank und viele Grüße,
    Thomas

    Hallo zusammen,


    einige weitere Tests scheinen nun darauf hinzudeuten, dass die Ursache der Events zwar im Raspi zu suchen sind, aber offenbar nicht softwareseitig. D.h. es gibt wohl keinen direkten Zusammenhang zwischen o.g. cronjob und dem Auslösen des Bewegungsmelders. Es wird nämlich noch viel lustiger:
    Selbst beim Anmelden per ssh am Raspi wird (reproduzierbar) der Bewegungsmelder ausgelöst. Ebenso, wenn ich absichtlich ein Script starte, welches die CPU signifikant auslastet. Es gibt auch Indizien, dass wirklich der Bewegungsmelder selbst auslöst (z.B. kann ich ein Neuauslösen erst dann forcieren, wenn die über R8 und C2 in pahs Schaltplan bestimmte Zeitdauer von knapp einer Minute abgelaufen ist).
    Ich sollte vielleicht noch erwähnen, dass mein Raspi direkt im Briefkasten verbaut ist und alle Komponenten (also auch die Timer-Schaltung für den Bewegungsmelder) über den Raspi versorgt werden, der wiederum per PoE gespeist wird. Mir kommt jetzt nur noch in den Sinn, dass es entweder unerwünschte Spannungsschwankungen oder unerwünschte Änderung der Wärmeeinstrahlung bei plötzlicher Erhöhung der CPU-Last des Raspi den Bewegungsmelder auslösen!? ?(
    Bleibt also erstmal nichts als weiter zu experimentieren...


    Viele Grüße,
    Thomas

    Hallo zusammen,


    bei mir läuft seit einiger Zeit DoorPi 2.5.1 auf einem Raspi 3 (Jessie) im Probebetrieb. Gestern habe ich testweise meinen Bewegungsmelder in Betrieb genommen. Es handelt sich um diesen Bewegungsmelder, der i.W. wie hier vorgeschlagen an den PiFace Digital 2, Eingang #2 angeschlossen ist. Die Hardware habe ich vorab in ausgebautem Zustand getestet und ich habe hinter dem MOSFET (Q2 im Schaltplan von PAH) ein zuverlässiges Signal erhalten, welches sich wie erwartet Verhalten hat.




    Für den Testbetrieb wollte ich erstmal nur das Auslösen des PiFace Eingangs protokollieren. Hierzu habe ich die folgende Konfiguration in der doorpi.ini gemacht (Auszug, entscheidend sind Zeile 6-7)



    Anmerkung: Da ich mit dem log-Befehl von DoorPi nicht zurechtgekommen bin (dieser scheint nur im trace-Modus des doorpi client zu protokollieren), verwende ich ein Shell-Skript, um die Nachrichten in das Protokoll zu schreiben.


    Das Mysteriöse ist nun, dass der Eingang 2 (bzw. das Event für Eingang 2) seit Testbeginn (gestern gegen 11:30) zuverlässig alle 30 Minuten ausgelöst hat. Das sieht dann im Protokoll doorpi.log so aus


    Ein Schaltungsproblem kann ich fast sicher ausschließen, denn dadurch ist ein solch präzises Auslösen alle 30 Minuten über mehr als einen Tag hinweg kaum erklärbar (und ab und zu gibt es auch "echte" Auslösungen wie z.B. um 21:36:53). Daher vermute ich eher, dass das Problem durch den Raspi (bzw. dessen Software) erzeugt wird.


    Ein Blick in /var/log/syslog offenbart Verdächtiges


    Jeweils um :09 und :39 läuft offenbar ein Cronjob. Ich vermute hier einen Zusammenhang, kann mir aber z.B. nicht erklären, warum dieser Cronjob zu einem solchen Seiteneffekt führen sollte und weshalb z.B. nur Eingang #2 betroffen ist. Für die anderen Eingänge sind ebenfalls Events auf die gleiche Art und Weise registriert und diese werden auf die gleiche Art und Weise protokolliert. Hier beobachte ich jedoch keinerlei falsche Auslösungen (an Eingang 0 hängt z.B. die Klingel, die ebenfalls über OnKeyPressed abgefragt wird - bisher hat es noch nie einfach so geklingelt ^^ ).



    Hat irgendjemand eine Erklärung für dieses Verhalten (und wie ich dieses Verhalten unterbinden kann)?


    Viele Grüße,
    Thomas

    Hallo,


    der Ansatz mit dem 10k oder 100k Widerstand gegen GND hat nicht geklappt.
    Vielleicht ist es mit Kanonen auf Spatzen geschossen, aber ich hatte noch einen 2N7000 in der Bastelkiste und den habe ich kurzerhand dazwischengeschaltet (wie in angehängtem Schaltplan skizziert) und dieser zieht den Schalteingang des Audio-Verstärkers zuverlässig auf GND.


    Viele Grüße,
    Thomas

    Hallo,


    vielen Dank für die Vorschläge.


    Wenn ich den ersten Vorschlag richtig verstehe, dann soll ich einen Widerstand R2 mit 10k oder 100k zwischen den Ausgang O1 des PiFace und GND legen. Das probiere ich auf jeden Fall mal aus. Wobei mir die Wirkweise nicht so ganz klar ist. Wenn T1/O1 des PiFace nicht durchgeschaltet ist, dann bilden R1 und R2 einen Spannungsteiler und an AUDIO_SW liegt eine Spannung von 5V * R2/(R1+R2) an. Wenn dadurch die Spannung auf > 0,65V "eingestellt" ist, dann würde ein Durchschalten von T1/O1 den Eingang AUDIO_SW maximal auf 0,65V runterziehen. Wenn die Spannung auf < 0,65V "eingestellt" ist (dazu müsste aber R2 << R1 gewählt werden), dann hat das Durchschalten von T1/O1 keinen Einfluss mehr auf die Spannung an AUDIO_SW.


    Was meinst Du mit "kann aber sein, dass Du einfach VCC schalten musst". Meinst Du damit, dass ich direkt die Stromversorgung des Foxnovo über den PiFace ein-/ausschalte und den Eingang AUDIO_SW gar nicht mehr verwende? D.h. man würde VCC des Foxnovo mit den +5V des PiFace verbinden (wie in meinem Schaltplan) und GND des Foxnovo mit O1 des PiFace?


    Den Punkt mit dem internen PullUp verstehe ich nicht. Ich dachte, die PullUp Widerstände wären für die Eingänge zuständig.


    Ein Relais auf dem PiFace habe ich leider keins mehr übrig. Sonst wäre das wahrscheinlich der schnellste Weg gewesen.


    Viele Grüße,
    Thomas

    Hallo zusammen,


    in meiner DoorPi-Lösung setze ich einen Foxnovo Audioverstärker ein, der über einen Schalteingang verfügt. Da ich keinen Arduino in meine DoorPi-Lösung eingebunden habe, habe ich den Schalteingang des Audio-Verstärkers nicht mit dem DLA-Ausgang der Arduino-Platine verbunden wie hier beschrieben, sondern habe ihn direkt mit einem Ausgang des PiFace Digital 2 verbunden (wie im Anhang skizziert; T1/R1 sind interne Bauteile des PiFace/Foxnovo über deren Typ/Dimensionierung ich keine Kenntnis habe).


    Leider klappt das Ausschalten des Audioverstärkers nicht. Nach einigem Nachmessen scheint die Ursache daran zu liegen, dass der Ausgang des PiFace Digital 2 es nicht schafft, den Schalteingang des Audio-Verstärkers auf GND zu ziehen. Stattdessen schafft er es "nur", diesen auf +0,65V zu ziehen. Einen Defekt des Audioverstärkers habe ich ausgeschlossen, d.h. wenn ich den Schalteingang direkt mit GND verbinde, dann bleibt er auch stumm.


    Das gleiche Verhalten zeigen übrigens auch die anderen (unbeschalteten) Ausgänge des PiFace Digital 2. Wenn sie durchgeschaltet sind, dann liegt im unbelasteten Zustand ebenfalls eine Spannung von +0,65V gegen GND an.


    Bevor ich jetzt anfange, irgendwas "aufwendiges" (Transistor/MOSFET/Optokoppler) dazwischenzuschalten, damit ich den Schalteingang des Audioverstärkers sauber auf GND ziehen kann, wollte ich doch mal kurz nachfragen:
    - hat jemand von Euch den Audioverstärker Foxnovo erfolgreich direkt am PiFace Digital 2 angeschlossen?
    - gibt es einen einfachen/einfacheren Trick, wie ich den Audioverstärker direkt über den PiFace Digital 2 ein-/ausschalten kann?


    Vielen Dank und viele Grüße,
    Thomas

    Hallo David,


    danke Dir für die Info. Ich habe keine FritzBox sondern eine Auerswald 5020 VoIP, aber ggf. hat die das gleiche Verhalten/Problem. Ich versuche dann als nächstes den Ansatz, den Verstärker erst dann einzuschalten, wenn die Sprachverbindung zustandegekommen ist.


    Viele Grüße,
    Thomas

    Hallo zusammen,


    ich habe seit einiger Zeit DoorPi 2.5.1 auf einem Raspi 3 (Jessie) laufen. Momentan verzweifle ich daran, den Wählton bzw. dessen Lautstärke zu beeinflussen. Wahrscheinlich sehe ich vor lauter Wald die Bäume nicht, aber irgendwie klappt es nicht.


    Zunächst habe ich es mit dem in der doorpi.ini vorhandenen Parameter dialtone_volume versucht.

    Code
    [SIP-Phone]
    ...
    dialtone_volume = 35


    Eine Änderung auf dialtone_volume = 1 brachte keine Veränderung. Der Wählton ist übrigens extrem laut, viel lauter als der spätere Gesprächston. Der Lautstärkeregler bei alsamixer sitzt bei 50%. Interessanterweise wird der Parameter dialtone_volume hier gar nicht (mehr?) aufgeführt. Vielleicht wird der Parameter daher gar nicht (mehr?) unterstützt.


    Der nächste Versuch war, die Lautstärke direkt in der WAV-Datei zu reduzieren. Also habe ich aus der ShortDialTone.wav eine neue Datei mit auf 10% reduzierter Lautstärke erzeugt. An meinem PC ist auch ein deutlicher Unterschied zu hören. Allerdings wurde auch die neue Datei mit der gefühlt gleichen Lautstärke an der Sprechstelle wiedergegeben.


    Dann bin ich hier auf die Information gestoßen, dass man den Parameter dialtone auch leer lassen kann, wenn man gar keinen Wählton abspielen lassen möchte. Also nächster Versuch mit



    Code
    [SIP-Phone]
    ...
    dialtone =

    Obwohl kein Wählton angegeben ist, wurde der gleiche Wählton wie bisher (und in der gleichen Lautstärke wie bisher) abgespielt.


    Irgendwie habe ich das Gefühl, dass o.g. Einstellungen komplett ignoriert werden. Wahrscheinlich mache ich einen systematischen Fehler, keine Ahnung. Hat irgendjemand das gleiche schonmal beobachtet oder irgendeinen Tipp, wie ich dahinter komme, was ich falsch mache?


    Danke Euch und viele Grüße,
    Thomas