Fragen zum DFPlayer mini (Lexikon)

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Ich hatte bisher bei allen meiner Projekte die Busy-Leitung immer direkt angeschlossen.
      Allerdings wurde das Modul nie mit 5Vdc betrieben sondern entweder die gesamte Schaltung mit 4Vdc oder mit 5Vdc und einer Diode im UB-Zweig des Moduls.

      Anbei auch ein neues Bild von meiner Testoberfläche. Die hat aber aktuell noch kein echtes Modul "gesehen", derzeit teste ich noch mittels 0-Modem und einem Terminalprogramm.

      DFpc.jpg
    • ftelektro schrieb:

      Mach mal in der Hardware Busyleitung noch einen 1kohm Widerstand zum Atmega . Ich kann mich erinnern,das ich bei meinem Project mit Busyauswertung ohne Widerstand Probleme hatte.Busy hat
      höchstwahrscheinlich auch 3,3V.
      Ich denke nicht, dass ich da Probleme bei der Auswertung habe. Es wird so sein, wenn das Modul den Befehl bekommt, dass es ein file spielen soll, dann braucht es erstmal Zeit, das file zu 'finden' und abzuspielen. In der Zeit ist das busy nicht aktiv. Wenn ich aber warten will, bis das file fertig gespielt wurde, um danach ein anderes abzuspielen, muss ich halt bisschen Warten (mit waitms), bis ich das busy auswerten kann, oder halt mit dem bitwait warten lassen. Nur wenn kein file gespielt wird, dann wird auch das busy nicht bedient und dann ist das bitwait unendlich lang.

      @Zitronenfalter da bin ich schon gespannt!
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • tschoeatsch schrieb:

      muss ich halt bisschen Warten (mit waitms), bis ich das busy auswerten kann, oder halt mit dem bitwait warten lassen
      Bitwait ist zwar bequem aber nicht so gut, hält den AVR rigoros an ... u.U bis zum reset ;) ,
      waitms ist zu starr...da müsste bekannt sein wie lange das in etwa dauern könnte...und macht in der Zeit auch nichts anderes als eben zu warten.
      Besser finde ich da ein Polling des busy-Eingangs...also ein permanenten Test des Busy...das stoppt den µC nicht.
      Nur mal so ne Idee trinkende-smileys-211
    • Das mache ich ja mit dem while busy=aktiv : wend. Aber bis ich das machen kann, muss ich irgendwie warten, bis busy auch aktiv wird, das ist das Problem.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Aktuell lasse ich in meinen Projekten im Prinzip einen "Timer" laufen nachdem ich den Play-Befehl ausgelöst habe.
      Genauer setze ich ein Flag setze einen Dauertimer der im IRQ läuft zurück und warte so auf Busy In dieser Zeit können dann keine weiteren Play abgestattet werdensondern eben erst nach Zeitablauf.
      Allerdings brauche ich aktuell das aktuelle Busy nicht exakt, daher geht das auch so.

      Ich kann mir aber vorstellen, dass das Modul da mithelfen kann, dies wird mit der aktuellen LIB aber nicht unterstützt.
      Es gibt z.B. ein ACK welches man anfordern kann, und auch so ist das Modul sehr "gesprächig". Alleine in der aktuellen LIB wird das einfach nicht ausgenützt.

      Mal sehen, was ich da noch "herausholen" kann wenn das Testtool mal soweit ist.
    • Zeitkritisch ist bei mir auch nix. Es hat nur Einfluß auf die Reaktionszeit auf einen Tastendruck. Ich werde mal versuchen, das Warten auf das aktive busy zu begrenzen und auch abbrechbar zu machen. Dann sollte das die Lösung in meinem Fall sein.

      Ich mach das jetzt so

      BASCOM-Quellcode

      1. Warte_auf_file_ende:
      2. Wartezeit = 255
      3. While Busy = 1 And Ausgabe_abbruch = 0 And Wartezeit > 0
      4. Decr Wartezeit
      5. Waitms 3
      6. Wend
      7. While Busy = 0 And Ausgabe_abbruch = 0 : Wend
      8. Return
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von tschoeatsch ()

    • Hm, der Mp3_standby() Befehl ist irgendwie eine Sackgasse als Einbahnstraße. Einmal gegeben, kommt man mit Befehlen nicht mehr raus. Wenn ich Stromsparen will, dann muss ich wohl den Player von Strom trennen und beim Wiederbenutzen neu initialisieren und die Lautstärke neu setzen. Das klappt leider nur mit Geräuschen beim Abschalten (Knacks) und Einschalten (Sirren). Außerdem hab' ich noch Probleme, wenn das Gerät zB. über Nacht im powerdown war und dann fortgesetzt werden soll. Da hat man zwar den Einschaltknacks gehört, es gab aber keine weiteren Ansagen. Bei einem stundenweisen powerdown hat das Fortsetzen immer funktioniert.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • tschoeatsch schrieb:

      Hm, der Mp3_standby() Befehl ist irgendwie eine Sackgasse als Einbahnstraße.
      Steht ja bei den beiden Befehlen :D , angeblich gibt es Module, wo das funktioniert, aber auch Module wo zwar das schlafen schicken funktioniert, aber das Modul dann nicht mehr aufgeweckt werden kann.
      Das steht aber IMHO nicht in den Datenblättern, sondern kam, soweit ich mich da erinnere, per "Stiller Post" zu mir.
      Ob und wie man die erkennen könnte, entzieht sich aber auch meiner Kenntnis.
    • Ich versuche gerade eine sichere Methode zu finden, wie ich feststellen kann, ob der player bereit ist. Dabei ist mir aufgefallen, dass nach MP3_init() als erstes byte ein &HFF und mit bisschen Verzögerung dann die erwartete Antwort mit den 10 bytes kommt. Hier mal ein screenshot von hterm
      Antwort auf reset.PNG
      Das ist wohl auch die Ursache, dass ein loop wie
      do
      modul=MP3_init()
      loop until modul=2
      nicht funktioniert.
      Oder ist das nur ein Effekt, weil der player bei mir am USB-dongle mit Strom versorgt wird? Es gibt ja jedesmal einen Einschaltknacks, obwohl die Stromverbindung jetzt nicht unterbrochen wird.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Das ist komisch a_27_b277ca12
      Ich habe ja jetzt tatsächlich einiges mit dem Modul durch, aber das habe ich bisher nicht beobachten können.
      Kann aber auch sein, dass ich derzeit allerdings nur bei der PC-App nach gültigen Zehn-Byte-Telegrammen suche (und somit nicht immer zwingend zehn Byte auslese) und nur diese auswerte und dadurch derartige "Störungen" gar nicht erst sehe (das macht die aktuelle BasCom-LIB derzeit aber auch nicht).

      Aber was ich auch anstelle (selbst die Stromversorgung mit zittrigen Fingern anlegen), bringt nur saubere Telegramme mit zehn Byte (auch bei anderen Terminalprogrammen).

      Was ich noch nicht habe, sind Versuche mit USB am Modul (da sind die Buchsen aus China erst im Zulauf).
      Daher kann ich aktuell nur mit SD-Karte testen.

      Siehst du dieses Extrabyte mit verschiedenen Modulen und an verschiedenen Schnittstellen?
    • Am player hängt direkt ein 220µ am VCC_player, der über eine Diode mit 5V betrieben wird. Es ist bei mir egal, ob ich den Player aus dem USB-dongle versorge oder aus einem separaten NT. Ob der Lautsprecher, der ja einen Knacks bei dem Befehl macht, dran hängt, ist auch egal. Ich hab' 2 Player probiert, einen mit dem YX5200 und einem mit dem clone drauf. Immer, mit etwas Verzögerung, erstmal ein FF, dann die Antwort.
      Aber, bei dem einen Player, mit der blauen statt roten Led und mit dem C statt R, fehlt das FF, es kommt nur die erwartete Meldung. a_28_2c02f089
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Sehr eigenartig, wenn das Playerabhängig ist ?(

      Was liefert die Funktion GetVersion oder wenn du dieses Telegramm (7E FF 06 46 01 00 00 FE B4 EF) direkt sendest?
      Als Antwort müsste 7E FF 06 46 00 00 05 FE B0 EF 7E FF 06 41 00 00 00 FE BA EF kommen wobei 05 das eigentliche fragliche Ergebnis ist.

      Alternativ ohne ACK der Befehl 7E FF 06 46 00 00 00 FE B5 EF sollte dann 7E FF 06 46 00 00 05 FE B0 EF liefern.
    • Wenn ich an den player Spannung anlege und die serielle Verbindung steht schon, dann liefern die rot leuchtenden immer dieses FF und anschließend die Antwort, die auf ein reset (Befehl 0C) auch kommen würde. Der blaue liefert gleich die Antwort.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------