Beiträge von Joker

    Zitat


    Wäre das Teil von Wolf Audio ggf. eine Option? Im Datenblatt habe ich nichts zu echo cancellation gelesen, aber die werben mit "Aufbau eines VoIP - Konferenztelefons möglich".


    In meinen Augen ist es keine Option, denn da steht dabei:



    Zitat


    Nur für Raspberry Pi A oder Raspberry Pi B, nicht für Raspberry Pi A+, B+, 2 oder3


    Vielleicht gibt es andere Soundmodule die Hardware Echo cancellation haben.
    In meinem Fall bringt die Echo cancellation von Linphone eine spürbare Verbesserung. Die Frage wäre, woran liegt das jetzt dass es bei mir gut funktioniert und bei anderen nicht :huh:
    Was man in jedem Fall machen sollte, ist die Mikrofon und Lautsprecher Kabel so kurz wie möglich zu halten, und Lautsprecher und Mikrofon so weit voneinander weg platzieren wie möglich. Ich teste morgen noch, ob es was bringt das Mikro von hinten mit schalldichtem Material zu isolieren.
    Weiterhin kann man mit Lautstärke des Lautsprechers und Empfindlichkeit des Mikrofons experimentieren. Je leiser der Lautsprecher und je un-empfindlicher das Mic, desto weniger Echo-Effekt. Hier muss man nicht unbedingt alles auf max haben um immer noch eine sehr gute Qualität zu haben. Ich habe z.B. das Speaker Volume auf 50 von 151. Bei 151 fliegen einem die Ohren weg.


    Kann jemand bitte das hier testen / validieren?
    https://lists.nongnu.org/archi…ers/2015-07/msg00024.html


    Also nachsehen ob neben dem linphonerc die genannte andere Datei liegt?
    Im Prinzip kein Thema, aber ich weiß schon nicht wo dieses linphonerc liegen sollte :D


    Beim Rest kann ich nicht wirklich helfen (hab keine Linux Kiste, und den dritten Punkt kapier ich nicht wirklich (vermute aber man muss Asterisk auf dem Pi laufen haben)).

    Ich habe damals ™ den Weg benutzt den Nea beschrieben hat, und das hat auch geklappt.


    Super dass du die Anleitung noch mal als extra Thread erstellt hast, so findet man das auch mal wieder. Halte ich Prinzip immer für eine gute Idee, wenn in einem Thread eine Lösung für ein Problem erarbeitet wird, die nicht direkt zum Thread-Thema gehört.

    Du musst auch bei den set-befehlen die richtige Karte auswählen mit -c1. Deine Ausgabe zeigt dass Du scheinbar bei der falschen Karte raus kommst.


    So müsste es gehen:


    Code
    sudo amixer cset -c1 numid=5 0

    Könnte ein anderer Codec denn wirklich an dem Echoproblem etwas verändern?


    AMR-WB wird häufig für Sprachübertragung verwendet, aber das wird scheinbar von der Fritzbox nicht unterstützt. Ich kenn mich aber nicht wirklich aus was der beste Codec für diesen Einsatzzweck ist.


    Das mit der Charakteristik klingt vielversprechend. Ein Elektretmikrofon (was scheinbar die meisten hier verwenden) hat soweit ich weiß auch eine Kugelcharakteristik oder? Also eigentlich schlecht.


    Mit dem Dämmen klingt auch gut. Ich werde mir glaube ich mal eine "Haube" aus Styropor schnitzen die ich hinten an das Mikrofon anbringe und schaue, ob das irgendwie hilft.

    Hi,


    in diesem Thread kam die Frage auf, wie man grundsätzlich die Sprachqualität verbessern kann:


    Wichtiger ist es, Mikrofon und LS akkustisch zu entkoppeln, um die Sprachqualität beim Gegensprechen zu erhöhen.
    Wirklich zufrieden stellt mich die Sprachqualität derzeit nicht... Muss da noch ein wenig experimentieren.


    Bietet linphone noch Möglichkeiten softwareseitig an der Sprachqualität zu schrauben?


    Ich mache dafür dieses eigene Thema auf, da ich das wichtig finde und mich es auch brennend interessiert.
    Welche Möglichkeiten gibt es grundsätzlich die Qualität zu verbessern?


    In der DoorPi Config kann man z.B.

    Code
    echo_cancellation_enabled = True


    einstellen. Ich habe mal gelesen dass man das nicht tun sollte, weil dem Pi die Rechenleistung fehlt. Ich habe das bei mir mal gemacht (wohlgemerkt auf einem Raspberry B+), und es hat einiges gebracht. Das Echo (habe ich nur an der Innenstelle, also am Telefon) tritt dadurch deutlich in den Hintergrund. "top" sagt mir während eines Gesprächs immer noch 20% Idle.


    Kann man die Option somit grundsätzlich einschalten?


    Wichtiger ist es, Mikrofon und LS akkustisch zu entkoppeln, um die Sprachqualität beim Gegensprechen zu erhöhen.
    Wirklich zufrieden stellt mich die Sprachqualität derzeit nicht... Muss da noch ein wenig experimentieren.


    Interessiert mich auch brennend, ich mache mal ein neues Thema dafür auf, denn sonst findet man das später nicht wieder und ich denke es ist wichtig.

    Also das ist jetzt nur noch stochern im Nebel, aber... alsamixer liegt normalerweise im Verzeichnis /usr/bin.
    Liegt er dort bei dir?


    Wenn nicht könntest Du ja die alsa-utils mal neu installieren (dort gehört der alsamixer dazu).


    Code
    sudo apt-get remove alsa-utils
    sudo apt-get install alsa-utils

    Hä, also mit deinem ALSA ist irgendwas defekt. Da hörts bei mir aber mit dem Wissen auf.


    Ich meine das hier im Log, keine Ahnung was das bedeutet:


    Jedenfalls sagt DoorPi, dass er nur ein Default Device findet:

    Code
    2016-03-25 22:54:36,438 [INFO]          [doorpi.sipphone.from_linphone] found 1 possible sounddevices:
    2016-03-25 22:54:36,444 [DEBUG]         [doorpi.sipphone.from_linphone] |rec|play| name
    2016-03-25 22:54:36,489 [DEBUG]         [doorpi.sipphone.from_linphone] | X | X  | ALSA: default device


    Trage doch mal "ALSA: default device" ein und schaue was passiert...


    edit: hier noch die Ausgabe die du wolltest:

    Hi,


    hier stelle ich mein DoorPi Projekt vor.


    Stand: 11.09.2016


    Status
    Mein DoorPi ist noch nicht im Produktivbetrieb. Aktuell bin ich am fertigstellen des Hardware-Aufbaus.
    Ich möchte dann hier die Erweiterungen/Änderungen immer aktualisieren.
    Die Informationen die hier stehen beziehen sich also immer auf den aktuellen Status. Wen die komplette History vom Anfang bis zum Erreichen des aktuellen Status interessiert, dem lege ich mein Worklog bei we-mod-it nahe.
    Wem hier Informationen fehlen oder wenn jemand Details wissen möchte, einfach Bescheid geben.


    Ausgangspunkt
    Ich bin Anfang März mit einem "nackten" Raspberry Pi gestartet (den hatte ich schon, habe ihn aber komplett neu aufgesetzt). Zu allen Schritten habe ich mir Notizen und auch teilweise ein paar Fotos gemacht, mein Plan wäre, dass ich diese im Lauf der Zeit zu einer Step-by-Step Anleitung für mein Projekt erweitere und zur Verfügung stelle.


    Hardware
    Ich gebe zur Hardware Links zu Bezugsquellen an. Das ist immer die Quelle wo ich selbst das Teil bezogen habe. Sicherlich gibt es vielleicht andere oder günstigere, aber zumindest hat man so sofort eine Quelle wo man die Teile beziehen kann





    Somit ist man bei reinen Hardwarekosten von etwa 150€ wenn man alles neu kaufen muss (geht noch etwas günstiger wenn man günstigere Quellen für die Teile sucht).


    Sonstige Teile


    Die Gegenstelle für den DoorPi ist eine Fritzbox 7390, an der ein FritzFon MT-F (DECT) sowie ein analoges Telefon (FON0) angeschlossen ist.


    Software

    • Raspbian Jessy
    • DoorPi 2.5.0.2
    • mjpeg-streamer
    • FHEM 5.7





    Realisierte Funktionen

    • Anruf per Tastendruck am DoorPi an die beiden Telefone
    • Anruf per Tastendruck am DoorPi an ein Handy (Umschaltung intern/extern erfolgt per Weboberfläche meines FHEM Home Automation Servers)
    • Erstellen eines Snapshots von der Kamera wenn geklingelt wird (bisher keine weitere Verarbeitung)
    • Dauerhafter Videostream von der Kamera, abrufbar per Browser-URL oder per Weboberfläche meines FHEM Servers)
    • Auslösen eines Relais am PiFace über DTMF-Töne (hier kommt später ein Türsummer dran)
    • Auslösen des Relais über RFID-Tag
    • Sprachausgabe bei Erkennen eines autorisierten RFID-Tags ("Hallo xxx") :D
    • Notifikation per Pushover, wenn jemand geklingelt hat, aber kein Anruf zustande gekommen ist
    • Notifikationen per Pushover, wenn DoorPi gestoppt oder gestartet wird
    • Betätigung des Türsummers von der Weboberfläche von FHEM
    • Beleuchtetes Namensschild, wird von FHEM bei Dämmerung ein- bzw. aus geschaltet (via Twilight)






    Aufbau
    Da es am besten zu meinen Gegebenheiten passt, habe ich mich entschieden die ganze Hardware in ein Aufputzgehäuse einzubauen, die später an der Garagenwand (dort ist auch die Gartentür) befestigt wird.



    Alle Platinen wurden dann auf einer selbst angefertigten Halteplatte aus Plexiglas (PMMA) befestigt. Die Halterung ist deswegen aus Plexiglas und nicht aus Metal, weil die RFID Antenne nicht funktioniert, wenn direkt dahinter eine Metallplatte ist. In die Plexiglasplatte habe ich Gewinde geschnitten, an denen ich meine Abstandshalter für die Platinen befestigen kann. Die Platte habe ich komplett in Handarbeit gefertigt.


    Das Mikrofon habe ich komplett entkernt, so dass nur die Mikrofonkapsel übrig blieb. Die einzelnen Hardwarekomponenten habe ich auf separate Platinen gelötet und etwaige notwendige Verschaltungen dort erledigt. Das hat den Vorteil, dass ich bei einem Hardwaredefekt einfach etwas austauschen kann. Alle Platinen wurde dafür auch mit Schraub-Anschlüssen versehen.


    Die Relais vom PiFace musste ich ablöten und ebenfalls auf eine Platine löten, denn sonst würde der Aufbau von der Höhe her nicht ins Gehäuse passen.



    So sieht aktuell der Aufbau im Gehäuse aus. Das Netzwerkkabel sowie das Stromkabel müssen natürlich noch nach hinten rausgeführt werden. Da muss ich aber noch auf Teile machen um den Ausschnitt an der richtigen Stelle machen zu können. Oben kommt natürlich noch eine Frontplatte drauf


    Hier die Beleuchtung in Betrieb. Die Platte ist ein Plexiglas Endlighten T. Über die Einspeisung an den Kanten leuchtet die Platte.


    Die Frontplatte besteht aus einem (einzigen) Stück transparentem Plexiglas, das ich von hinten schwarz lackiert habe. Das Beschriftungsfeld habe ich frei gelassen. Somit habe ich schonmal keine Dichtigkeitsprobleme zum Beschriftungsfeld hin, denn das ist ja ein Teil. Bohrungen etc. sind von Hand gemacht.


    So sieht das ganze dann im Gehäuse aus, an der Frontplatte sind die Kamera und der Taster angebracht.


    Fertig zusammengebautes Gehäuse.


    TODO

    • Wasserdichte Durchführung der Kabel aus dem Gehäuse
    • Weitere Software-Spielereien --> je nach Bedarf
    • Echo-Problematik in den Griff bekommen


    Updates
    25.03.2016 Initiale Version
    31.03.2016 Informationen zum geplanten Gehäuse
    03.04.2016 Neuer Hardwareaufbau mit Beschreibung
    17.04.2016 Infos zur neuen Halteplatte
    08.05.2016 Infos zur Beleuchtung ergänzt
    11.09.2016 Infos zur Frontplatte ergänzt

    Ah stimmt, guter Punkt, das hatte ich auch nicht mehr auf dem Schirm. Bei mir steht auch "ALSA: <devicename laut aplay --list-devices>" in der Config.
    Aber mach es am besten wie Nea gesagt hat, dann passt es auf jeden Fall.

    Schlecht :D


    Ist das Modul für deine Soundkarte geladen?


    Gib mal

    Code
    lsmod


    ein. In der Liste sollte ein Treiber für usb audio auftauchen.


    Und in DoorPi hast Du das richtige Playback device gewählt?


    Code
    aplay --list-devices


    Du solltest ein hier auftauchendes Device (sollte ja eigentlich nur noch eins sein) in der DoorPi Config eintragen (nicht Default oder sowas).

    Bei mir gehts auch, ich habe mal diesbezüglich bei Debian noch mal nachgelesen.


    Zitat


    Create a file '/etc/modprobe.d/<modulename>.conf' containing 'blacklist <modulename>'.


    So habe ich es dann gemacht. Es einfach in eine allgemeine blacklist.conf zu schreiben geht scheinbar auch, ich denke es kommt nicht auf den Namen an, Hauptsache es gibt ein File mit dem blacklist <modulename> Inhalt :)

    Hi,


    in diesem Thema ging es unter anderem darum, vom DoorPi eine Handynummer anstatt eines internen Telefons anzurufen. Weiterhin wurde kurz beschrieben, wie man zwischen intern und extern umschalten kann.


    Ich habe das jetzt noch ein wenig weiter verfolgt und die Umschaltung in mein FHEM eingebunden. Hier die Anleitung dazu:


    Im DoorPi drei Tasten mit Actions belegen:
    Taste1: Nummer aus Datei anrufen
    Taste2: interne Nummer in Datei schreiben
    Taste3: externe Nummer in Datei schreiben


    Zum Beispiel so:


    Code
    [EVENT_OnKeyUp_0]
    10 = file_call_value:/usr/local/etc/DoorPi/tools/call.txt
    
    
    [EVENT_OnKeyUp_1]
    10 = os_execute:echo **701 > /usr/local/etc/DoorPi/tools/call.txt
    
    
    [EVENT_OnKeyUp_2]
    10 = os_execute:echo 0172xxxxxxx  > /usr/local/etc/DoorPi/tools/call.txt


    Dann in FHEM einen dummy anlegen, der den Wert "internal" und "external" haben kann.

    Code
    define doorBellTarget dummy


    Dann ein notify, welches auf Änderungen des dummys reagiert:

    Code
    define onDoorBellTarget notify doorBellTarget:.* { onDoorBellTargetState($EVENT) }


    Und letztendlich den Inhalt der Funktion, der per HttpUtils am Webinterface von DoorPi je nach Wert eine der beiden Tasten auslöst, die die Nummern in die Datei schreiben. Diese kommt in FHEM in die Datei 99_myUtils.pm:



    Die URL ist entsprechend die eigenen Gegebenheiten anzupassen (User/Password/IP/Port/Key etc..)


    Dann habe ich mir noch zwei schicke Buttons für die Visualisierung gemacht, und schon kann ich per Tastendruck umschalten. Sieht dann so aus:

    Naja, doch kann schon. Aber der Raspi ist da wohl eher robust ausgelegt.
    Fakt ist dass er 3.3V an seinen Eingängen erwartet und der RDM legt 5V an. Da er anscheinend bei vielen so läuft hat der Pin dadurch bisher keinen Schaden genommen.
    Ich persönlich würde es ändern. Das dauert ja keine 10 min.

    In etc/modprobe.d gibt es bei mir nur folgende Dateien:


    fbdev-blacklist.conf
    ipv6.conf
    libpisock9.conf
    raspi-blacklist.conf


    Müsste man die blacklist.conf dann anlegen?

    Super Sache.


    Leider gibts für meine 7390 noch nicht das Update 6.50. Ist laut AVM Seite aber in Vorbereitung. Wenn das kommt ist das so für mich eine völlig ausreichende Lösung. Die Krücke mit dieser Elcom App fürs Smartphone gefällt mir nicht wirklich.