Nexus 5 soll 19-kHz-Pulse ausgeben - statt dessen kommt EKG

Will man ein Handy als Infrarot-Fernbedienung benutzen, kann man mit einem geeigneten Programm 19-kHz-"Morsesignale" erzeugen und an den Kopfhörer-Anschluss einen Infrarot-Adapter (mit Frequenzverdopplung) anschließen. Das ist inzwischen "Stand der Technik" (Beispiel: Irdroid). Mein Nexus 5 mit Android 6.0 verbeult diese Morsesignale aber so, dass sie unbrauchbar sind, wie das Bild zeigt:

In der oberen Hälfte des Bildes sind solche vom Oszillographen abfotografierten 19-kHz-"Morsesignale" zu sehen, die so sind wie wie sie sein müssen. Sie sind von einem Medion Lifetab P9516 mit Android 4.0.3 erzeugt worden. In der unteren Hälfte sind die mit dem selben Programm (s.u.) erzeugten Signale meines Nexus 5 zu sehen (gleicher Oszillograph, gleicher Maßstab) und sind unbrauchbar. Es sieht so aus, als ob das Nexus 5 die vom Programm erzeugten 19-kHz-Signale noch mal intern mit einer zu niedrigen Frequenz abtastet, bevor es sie auf den Kopfhöreranschluss jagt, und dann schlägt das "Abtasttheorem" zu. Oder als ob es die Signale erst betragsmäßig mittelt und dann differenziert und erst dann rausjagt. Weiß jemand was genaueres darüber, wie das Nexus 5 das intern macht und ob/wie man das beeinflussen kann? Oder findet jemand einen Fehler in dem Testprogramm (auf dem Medion P9516 funktioniert es ja richtig)? Hier das Testprogramm:

package com.example.hfmarkspace;

import android.support.v7.app.ActionBarActivity;
import android.content.Context;
import android.media.AudioFormat;
import android.media.AudioManager;
import android.media.AudioTrack;
import android.os.Bundle;
import android.os.Handler;
import android.view.Menu;
import android.view.MenuItem;

public class MarkSpaceMainActivity extends ActionBarActivity {

byte generatedSnd[];                // byte array for audio track
Handler mHandler = new Handler();   // for repeated play of audioTrack
AudioTrack audioTrack;
AudioManager audio;
int streamMaxVolume;
int delay = 100;
int scanRate = 38000;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_mark_space_main);
    audio = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
    streamMaxVolume = audio.getStreamMaxVolume(AudioManager.STREAM_MUSIC);
    audio.setStreamVolume(AudioManager.STREAM_MUSIC, streamMaxVolume, 0);

    // calc. & fill audio buffer
    int buffSize = AudioTrack.getMinBufferSize(
            scanRate, AudioFormat.CHANNEL_OUT_STEREO,
            AudioFormat.ENCODING_PCM_8BIT);
    generatedSnd = new byte[buffSize];
    int i = 0;
    for (int k=0; k<8; ++k) {           // 8 mark-spaces
        for (int j=0; j<5; ++j) {       // 5 mark wavelets
            generatedSnd[i++] = 0;
            generatedSnd[i++] = -1;     // = 255
            generatedSnd[i++] = -1;     // = 255
            generatedSnd[i++] = 0;
        }
        for (int j=0; j<24; ++j) {      // 6 space wavelets
            generatedSnd[i++] = 127;
        }
    }
    for (int k=i; k<buffSize; ++k) {    // trailer spaces
        generatedSnd[k] = 127;
    }

    // play audio buffer in endless loop
    mHandler.post(rept);
}

private Runnable rept = new Runnable() {public void run() {
    mHandler.removeCallbacks(this);
    if (audioTrack!=null) {
        audioTrack.flush();
        audioTrack.release();
    }
    audioTrack = new AudioTrack(AudioManager.STREAM_MUSIC,
            scanRate, AudioFormat.CHANNEL_OUT_STEREO,
            AudioFormat.ENCODING_PCM_8BIT, generatedSnd.length,
            AudioTrack.MODE_STATIC);
    audioTrack.write(generatedSnd, 0, generatedSnd.length);
    audioTrack.play();
    mHandler.postDelayed(this, delay); 
}};


@Override
public boolean onCreateOptionsMenu(Menu menu) {
    // Inflate the menu; this adds items to the action bar if it is present.
    getMenuInflater().inflate(R.menu.mark_space_main, menu);
    return true;
}

@Override
public boolean onOptionsItemSelected(MenuItem item) {
    // Handle action bar item clicks here. The action bar will
    // automatically handle clicks on the Home/Up button, so long
    // as you specify a parent activity in AndroidManifest.xml.
    int id = item.getItemId();
    if (id == R.id.action_settings) {
        return true;
    }
    return super.onOptionsItemSelected(item);
}

}

Nein, hab ich nicht, wäre auch nur von wissenschaftlichem Wert. Infrarot-Fernbedienungen brauchen nun mal 19kHz-Signale (bzw. 38kHz nach Frequenzverdoppelung im Infrarotadapter), weil die Infrarotempfänger im Fernseher sie sonst nicht lesen können. Die Hörgrenze von genügend jungen Leuten liegt übrigens bei 20kHz, deshalb schaffen normale Handys auch die 19kHz.

Ich erinnere mich dunkel, mal irgendwo gelesen zu haben, dass Android 6.0 ein verschlimmbessertes Audio-API hat, das so eine Art Rauschunterdrückung macht, wobei es sich wahrscheinlich an den höheren Frequenzen vergeht. Kann sein, dass es einen Funktionsaufruf gibt, durch den man diese "Verbesserung" deaktiviert, habe aber keine Ahnung, wo man den findet. Wenn ich in der offiziellen Google-Androidprogrammierdokumentation suche, kriege ich einen Informationsinfarkt.

Danke für die Links auf die beiden Beiträge. Die hatte ich allerdings auch schon gelesen und das hatte mich dem erwähnten Informationsinfarkt nahe gebracht.

Das Nexus zum Test auf 5.0 oder 4.4 zurückflashen um zu sehen an was es liegt, damit hätte ich wirklich ein Problem. Vielleicht habe ich Glück und jemand hat einen Oszillographen und ein Nicht-Nexus-Smartphone mit Android 6.0 und lässt das Programm aus meinem Ur-Beitrag mal darauf laufen. Oder kommt mit dem Gerät für ein Freibier mal kurz vorbei.

Ich habe das Ganze jetzt mal mit einem Moto G2 mit Android 5.0.2 drin getestet. Kommt nur totaler Schrott raus. Amplitude nah bei 0, kein Zusammenhang zwischen dem was rauskommt und den beabsichtigten Pulsen zu erkennen. Um sicher zu gehen, dass ich nichts übersehe und dass der Oszi nicht zickt, habe ich das Oszi-Kabel abwechselnd zum Nexus 5 und zum Moto G2 hin und her gesteckt. Nexus macht Pulse wie oben angegeben (zwar nicht wie gewollt, s.o., aber immerhin reproduzierbar), Moto nur Schrott.

Kann das nicht auch an der Hardware liegen, das der Chip der die Signale analgo Wandelt, ein anderer ist und es deswegen nicht tut?

Kann ich mir eigentlich nicht vorstellen, denn wenn ich statt des Oszillographen einen normalen Kopfhörer anschließe und mit dem an Stelle meines Testprogramm-Auspuffs normale Musik höre, hört sich die Musik für meine Begriffe ganz normal an. Und auf dem Oszi scheint diese normale Musik auch ganz normal auszusehen.

Außerdem hat Google nach meiner Kenntnis ziemlich strenge Richtlinien dafür erlassen, wie Androiden hardwaremäßig funktionieren müssen. Wenn das Moto G wegen nicht spezifikationsgerechter Hardware so zickt, müsste Motorola ins Google-Gefängnis einrücken...

Michael K.

Ich glaube schon, dass das an der Hardware liegen kann. Die Kopfhörerschnittstelle ist für die Ausgabe von AC-Signalen konzipiert, eine Infrarotdiode wird normalerweise mit gepulstem DC betrieben. Handelt es sich beim Kopfhörerausgang um eine kondensatorlose Vollbrücke, ist das Banane, weil die IR-Diode in Durchgangsrichtung schon etwas zum Leiten gebracht wird, und ansonsten einfach sperrt.
Ist der Kopfhörerausgang aber eine Halbbrücke mit Kondensator zum Entkoppeln des bei Halbbrücken vorhandenen DC-Anteils, so lädt die Diode den Kondensator einfach auf, wie eine Einweggleichrichterschaltung. Ich möchte also behaupten, die nicht sehr professionell wirkende Lösung kann nur an Kopfhörer Ausgängen in Vollbrückenschaltung funktionieren, die offenbar nicht überall realisiert ist.
Gibt's nicht so was für den USB-on-the-go?
Anderer Vorschlag: Häng an den Kopfhörer Ausgang einen Widerstand (100 bis 500 Ohm) und schließe dann extern einen Komparator z.B. LM311 oder einen als Komparator geschalteten OP (weniger gut, z.B. LM324) mit dualer Stromversorgung von z.B. +/- 3V an. Bei dieser Spannung kann die IR-Diode entweder am Open-Kollektor-Ausgang des Komparators (mit Vorwiderstand) gegen die Plusspannung betrieben werden, oder am Halbbrückenausgang des OP von Plus gegen den Ausgang, vom Ausgang gegen Masse oder gegen Minus. Die Reichweite wird aber begrenzt bleiben. Ein weiterer 1 A Transistor kann aber auch diese Problem lösen.
Der Kophörerausgang ist ja Stereo, aber Du kannst ja ausmessen, welcher Kanal benutzt wird.

Ich glaube du hast das falsch verstanden. Es geht hier nicht um die Infrarot-Umwandlung. Die Infrarot-LEDs sind nicht direkt an den Kopfhörer-Anschluss angeschlossen, sondern über einen speziellen Adapter (hier: "Irdroid"), und die Umwandlung macht kein Problem. Mein Problem sind die direkten Kopfhöreranschluss-Ausgangssignale, die ich mir auf dem Oszillographen angesehen habe, der Adapter ist bei diesen Tests überhaupt nicht angeschlossen. Und diese direkten Kopfhöreranschluss-Ausgangssignale sind beim P9516 richtig, beim Nexus 5 reproduzierbar falsch und beim Moto G Schrott.

Pascal P.

Klingt plausibel, damit ist das Vorhaben nur auf speziellen Geräten machbar.
Die Frage ist ob das Signal schon passend ausgegeben wird oder ob das auch schon nicht geht.

OTG Infrarot gibt es übrigens relativ billig z.B.: "Um Spam in unserem Forum zu vermeiden, können neue Mitglieder vorerst keine Links auf externe Webseiten veröffentlichen."

Edit:

Gerade mal bei mir Probiert, statt den alten Oszi aus dem Keller zu kramen hab ich jetzt eine Aufnahme mit Audacity durch den Line Eingang meines Notebooks gemacht. Sollte wenig unterschied machen.
Bei mit sieht das recht gut so aus:
![image][1]

[1]: https://fscl01.fonpit.de/userfiles/2927890/image/19kHz.PNG

Das Signal wird so "passend" augegeben, wie es in der Abbildung meines "Ur"-Beitrags zu sehen ist, d.h. beim P9516 richtig, beim Nexus 5 reproduzierbar falsch und beim Moto G komplett schrottig.

Die OTG Infrarot-Reklame hab ich auch mal gesehen. Hier scheint die IR-LED direkt ohne Verstärkung an den Kopfhöreranschluss angeschlossen zu werden müssen, und dann ist sie entweder nicht hell genug (funktioniert dann nur über ganz geringe Entfernungen, je nach Handy) oder das Handy geht gleich ganz kaputt (je nach Handy), weil die LED womöglich zu viel Strom zieht. Der Adapter, den ich benutze ("Irdroid"), ist im Wesentlichen ein Analog-Verstärker mit angeschlossenen IR-LEDs.

Die Idee mit Audacity finde ich toll. Offensichtlich macht dein Note3 mit 5.0 das selbe Ungewollte wie mein Nexus 5 mit 6.0.

Kann natürlich prinzipiell auch noch sein, dass mein Programm (s. Ende meines Urbeitrags) noch irgendeinen gemeinen Fehler hat, der sich nur beim alten P9516 nicht auswirkt.

Nachtrag am 25.11.2015:

Ich habe mal ein Bisschen mit den Parametern gespielt und das mit Audacity getestet und dann gemerkt, dass die von Audacity angezeigten Pulse offenbar sehr von der Rechner-Hardware abhängen, zumindest in der Nähe der 20 KHz-Grenze. Hier das Oszi-Bild (nur mit den ersten 3 von insgesamt 10 Puls-Paketen):

Das Ganze jetzt mit Audacity in einem Asrock G31M-GS aufgenommen (die ersten 3 Pakete mit dem Oszi-Bild vergleichen):

und jetzt das Ganze noch mal mit einem Toshiba Satellite R630 (wieder die ersten 3 ankucken und sich wundern):

D.h. Audacity zum Pulse testen in der Nähe der 20 KHz-Grenze: lieber nicht. Offensichtlich verbiegen die Mikrophon-Eingänge des Rechners die höheren Frequenzen je nach Rechner unterschiedlich stark, ähnlich wie die neueren Smartphones das bereits mit den Kopfhörer- und Bluetooth-Ausgängen machen.

— geändert am 25.11.2015, 17:23:15

Michael K.

Man könnte mal nur gegen den Widerstand messen, das ist ja kein grosser Aufwand. Dann sieht man, ob die Geräte die Signale prinzipiell richtig ausgeben oder nicht, und ob sich weiterer Aufwand lohnt. Möglich wäre auch, dass die Geräte noch Filter- und Klangverbesserungsstufen enthalten, die man erst deaktivieren muss, sofern das überhaupt geht. Ich habe übrigens mal so eine USB-Soundkarte für 3,50 € oder so am Moto G2 betrieben. Ging ohne Treiber-Installation auf Anhieb (der Klang bei dem Billigteil war aber schlechter als am Kopfhörer-Ausgang). Wäre vielleicht auch noch ein Ansatz, auch um den Kopfhörer Ausgang vor Zerstörung zu schützen.

Ich hab mal einen 100-Ohm-Widerstand direkt an den Kopfhörerausgang drangehalten. Signal wird ein ganz kleines Bisschen schwächer, vielleicht 5%, Signalform bleibt unverändert.

Nachtrag: Außerdem habe ich das Ganze mal über Bluetooth ausprobiert, also Bluetooth am Nexus aktiviert und Kopfhörerausgang eines Bluetooth-Audio-Adapters auf dem Oszi angesehen. Ergebnis genau so wie am Kopfhörerausgang des Nexus. Falls das Nexus eine Analog-Endstufe hätte, die die programmierten Signale zu seinem Kopfhörerausgang hin verbiegt, wäre es ein mittlerer Zufall wenn der Bluetooth-Audio-Adapter das genau so machen würde. Der Fehler (bzw. das "Feature") liegt also wohl irgendwo im Digitalgestrüpp.

— geändert am 09.11.2015, 12:39:06