Marco's Affenbox Fork

Software
61

Hallo,
erstmal vielen Dank für die Software.
Eine kurze Frage: Ich habe Probleme wenn

#define STARTUP_SOUND

und

#define POWER_ON_LED

beide aktiviert sind.

In diesem Fall höre ich beim Starten der Box den Startsound, danach passiert allerdings nichts mehr. Der Tonuino reagiert nicht auf Tastendrücke und auch nicht auf die Karten. Auch die LEDs auf der Platine beginnen nicht zu blinken wie sonst üblich. Die Debug Ausgabe zum Start kommt jedoch. Wenn ich 20-30 mal neustarte kann es vorkommen, dass bei irgendeinem Versuch der Start gelingt.
Wenn ich eins der beiden Features auskommentiere ist die Welt wieder in Ordnung.

So sieht mein DEFINE-Block aus:

//#define FIVEBUTTONS
#define DEBUG
//#define DEBUG_QUEUE
#define PUSH_ON_OFF
#define STARTUP_SOUND
//#define SPEAKER_SWITCH
//#define ROTARY_ENCODER
//#define ROTARY_SWITCH
#define POWER_ON_LED

Ist hier was bekannt?

EDIT:
Wo wir gerade dabei sind:

In Zeile 3311 musste ich
digitalWrite(PowerOnLEDPin, Low);

in

digitalWrite(PowerOnLEDPin, LOW);

ändern, sonst meckert der Compiler.

62

Hallo @JMangerich, ich benutze ebenfalls beide Funktionen gleichzeitig. Habe allerdings nie solche Probleme gehabt. Vielleicht liegts an schlechten Kontakten!?

Gruß

63

Hallo zusammen,

der Fehler ist gefunden. Es war mal wieder so ein Fehler den man nur mit Glück findet.

Irgendwann ist mir aufgefallen, dass der Player durchstartet sobald ich Pin 4 mit dem Schraubendreher berühre. Also nachgeschaut Pin 4 -> Busy. Da war alles klar.

Der Busy Pin hatte ein Kontaktproblem und hing daher mit dem Potenzial in der Luft. Scheinbar hat die Spannung durch „POWER_ON_LED“ das Potenzial derart beeinflusst, dass das Verhalten anders war.

Jedenfalls jetzt gehts, vielen Dank!

VIele Grüße
Jan

64

Eine Frage an @marco-117 und alle die seine Software verwenden:

Ich habe nun ein Problem festgestellt. Der Fehler passiert immer nachdem ein Track komplett zu Ende gespielt wurde und dann der nächste Track bereits angefangen hat zu spielen. Drückt man nun den Zurück Knopf beginnt das vorherige Lied von Anfang an zu spielen. Soweit alles gut. Doch nachdem dieses Lied zu Ende ist, bleibt die Wiedergabe stehen. Die Box geht auch nicht automatisch aus.

Wenn der Fehler bei meinem Sohn passiert, merkt er gar nicht das der TonUINO noch an ist und irgendwann ist auch der Akku leer. Das ist nicht so gut.

Ich habe diesen Fehler bei beiden TonUINOs, die ich gebaut habe und die mit der Software von @marco-117 laufen. Hat einer eine Idee woran das liegt? Oder hat evtl einer diesen Fehler auch schon beobachtet? Habe versucht das Problem selbst zu lösen, leider ohne Erfolg. Würde mich über jede Hilfe freuen.

Hier die Konsolenausgabe:

TonUINO Version 2.1
created by Thorsten Voß and licensed under GNU/GPL.
Information and contribution at https://tonuino.de.

Fork by Marco Schulz + mods by Oberbad
load settings from flash
Version: 2
Max Vol: 30
Min Vole: 5
Init Vol: 15
EQ: 1
Locked: 0
Sleep Timer: 5
Inverted Vol Buttons: 0
Admin Menu locked: 0
Admin Menu Pin: 1111
Saved Modifier Mode: 0
set standby timer
milis: 302137
Firmware Version: 0x12 = counterfeit chip
=== mfrc522-> RxGain_avg === 
_lastTrackFinished
_lastTrackFinished
ReadCardSerial finished
Card UID 
00  8F  C1  59 
PICC type MIFARE 1KB
Authenticating Classic using key A...
Reading data block4...
Data on Card :  13  37  B3  47 02 01 02  10  64  19  B3 00 00 00 00 00 
1
1
new card
playFolder
disable standby timer
17 tracks in folder 1
Album
play track: 1
next track: disable standby timer
2
_lastTrackFinished
previous track: disable standby timer
1
_lastTrackFinished
_lastTrackFinished

Vielen Dank und viele Grüße

65

Was bedeutet eigentlich die Ausgabe _lastTrackFinished? Bedeutet es, dass der letzte Track des Ordners beendet wurde, oder dass der aktuell abgespielte Track zu Ende ist? Diese Ausgabe verwirrt mich etwas. Vor allem das wird ja auch schon ausgegeben, bevor ich eine Figur auf den TonUINO stelle.

Hmm…

66

Das _lastTrackFinished ist ein Konstrukt um dem Verhalten des DF Players entgegen zu wirken.
Dieser sendet mehrmals die Info „Track zuende“.
Wie eine Art prellen bei einem Taster.
Das führt dazu das die SW zwei. Oder drei Tracks überspringen würde.
So wird quasi nur der Erste Trigger des Players aufgenommen und abgefragt ob der letzte angespielte Track schon Fertig ist, um zum nächsten zu springen.
Bei kurzen Tracks funktioniert das manchmal nicht sauber, das ist noch nicht optimal.
Aber derDF Player macht es einem auch nicht leicht.

Dein Problem schau ich mir gerade an, mal sehen ob ich den Bug finde.

67

Ich denke ich habe das Problem.

Es wird der aktuelle neue Titel bei dem Ereignis nextTrack gespeichert, um das mehrmalige Aktivieren des DF Palyers ab zu fangen.
Im Falle des previousTrack, merke ich mir aber nicht den neuen Track.

So ist in deinem Fall Track 1 aktiv, aber Track 2 im speicher.
Wenn jetzt wieder Track 2 gespielt werden soll, vergleicht er was im Speicher steht und merkt, der Titel ist noch aktiv.
Das führt dazu das er den neuen Track 2 nicht spielt, weil er für das Programm wie ein doppel Befehl des DF Palyers aussieht.

Ich hoffe ich hab das einigermaßen Nachvollziehbar beschrieben.

Ich behebe das und versuch es zu testen, dann könnt ihr euch morgen die Aktualisierung herunterladen.

Für diejenigen, die eine abgeänderte Form meines Fork nutzen, werde ich die Zeile Code hier noch posten.

Update:

Ich denke mit dieser Anpassung sollte es gehen:
Ab Zeile 1380:

static void previousTrack() {
  bool queueTrack = false;
  
_lastTrackFinished = 0; //Das hier einfügen

Ich konnte das Problem nachstellen und in einem kleinen Test hat die obige Ergänzung das Problem behoben.
Der Fork ist jetzt auch online.

68

Ach du lieber Himmel, dachte schon dass es etwas komplexer ist als ich mir das vorgestellt hatte. Aber das ist schon krass was da so im Hintergrund passiert. Danke dir für die ausführliche Erklärung und die Fehlerbeseitigung :+1: Wie immer TOP von dir.

Danke nochmal und schönen Gruß.

1 „Gefällt mir“
69

Gerne.

Mir liegt schon sehr daran, dass der Fork Fehlerfrei funktioniert.
Und es ist mir leider nicht Möglich jedes Ereignis selbs ab zu testen.

Ich sehe in deiner Konsolenausgabe, dass du meinen Fork modifiziert hast? Zumindest hast du dich undter „Fork by“ verewigt.

Mich würde interressieren, was das für Änderunge sind, vieleicht macht es Sinn dies ein zu pflegen.

Edit:
ist das nur der weiter Oben von dir beschriebene Ordner Ende Sound ?

70

Meine Modifizierungen sind eher kleinere Anpassungen an die gegebene Hardware. Hier habe ich eine Methode zu einer Intervallbelastung einer Powerbank, die nach einer gewissen Zeit automatisch ausgehen würde, eingebaut. Das habe ich per #define ausschaltbar gemacht, da nicht jede Powerbank das benötigt. Weiterhin habe ich die Delays für die Tastendrücke als definierbare Variablen gestaltet. Das Thema mit dem Sound abspielen am Ende eines Ordners war eine Idee, doch leider bin ich noch nicht weiter gekommen.

Das mit dem Namen im Fork war eher für mich gedacht, damit ich weiß welche Version von dir ich bereits angepasst habe. Also eher für „interne Zwecke“ gedacht. Sollte dich das stören, nehme ich das natürlich raus.

Gruß

71

Das stört mich nicht, ich habe das ja selbst nur vom Original kopiert :wink:

Die Tastedelays sind bereits als #defines drin

#define LONG_PRESS 1000
#define LONGER_PRESS 2000
#define LONGEST_PRESS 5000

Diese Intervallbeschaltung habe ich ehrlich gesagt nie ganz verstanden, aber es gibt auch in meinem Fork dafür eine simple Lösung

Folgende #defines schaltet einen Pin zu/ab um eine Powerbank wach zu halten.
#define POWER_ON_LED
#define PowerOnLEDPin 6

Der Pin ist default Nr 6. An diesen Pin muss dan eine Last in Form eines Widerstands oder einer LED.

72

Die POWER_ON_LED Funktion nutze ich ebenfalls. Hat bei meiner Powerbank (RAVPower) leider nicht ausgereicht. So musste ich was zusätzliches machen.

Hier die DEFINES:

#ifdef POWERBANK_LOAD
	#define LoadPin 5	//Pin D5 für Lastschaltung zur Belastung der Powerbank (Verhinderung des Auto-Off)
	unsigned long MillisAktuell = 0;
	unsigned long LoadStart = 0;
	bool LoadEinAus;
	unsigned long ZeitLoad = 1000;	//Belastungszeit in ms
	unsigned long ZeitIntervall = 10000;	//Intervall zur Impuls-Lastschaltung (Powerbank-Belastung) in ms
#endif

#define LONG_PRESS 1000
#define LONGER_PRESS 2000
#define LONGEST_PRESS 3000

#define VOLUME_DELAY 200
#define TRACKJUMP_DELAY 150

Die POWERBANK_LOAD Funktion läuft dann alle 10 s für 1 s. Ist aber auch anpassbar. Damit ich mehr Strom beim Verbraucher generieren kann, benutze ich eine Transistorschaltung mit Widerstand. Ich habe noch zusätzlich die Delays für die Lautstärkeänderung und Titelsprung anpassbar gemacht.

73

@marco-117, ich hab die Änderungen nun auch getestet. TOP :+1: läuft wunderbar. Vielen Dank nochmal für die Hilfe :blush:

Gruß

74

Ich habe meinen Fork soeben wieder aktualisiert.

Es gab Probleme mit der Speicherbelgung bei den Hörbuchspeichern. @kobayashi_maru hat eine Lösung dafür gefunden.

Außerdem hatte @kobayashi_maru eine Verbesserung für den ShutDown Sound beigetragen. Hier gab es ein Problem bei volleren SD Karten.

Desweiteren ist die Push On/Off Funktion verbessert worden.
@Magge hatte einen Vorschlag um den Aufrauf des ShutDowns zu präzisieren.

Update:
Ich habe gerade noch eine Funktion eingefügt um den Hörbuchspeicher zurück zu setzen.
Ein sehr langer Druck (2s) des up & down Buttons, setzt den Speicher auf 0 zurück.
Die Funktion ist leider ungetestet.

2 „Gefällt mir“
75

Mein Fork ist nun auch kompatibel mit der AiO.

Allerdings nur in einer Developer Version (im „develop“ Branch), da ich noch einige Anpassung bezüglich Shortcuts und erweiterte Eingabemethoden implementiere(Fernbedienung, Tastenfeld), sowei ein weiters Spiel(The Quest).

Beim ersten Schnelltest liefen alle Grundfunktionen.
Interressant im Bezug auf die AiO ist:

  • 3 Buttons möglich
  • DF Player „Startsound“/Störgeräusch beseitigt und durch einen eignen Startsound ersetzt.(ehemals „SPEAKER_SWITCH“)
  • Ausschalten über einen langen Druck des Pausetasters (ehemals „PUSH_ON_OFF“)

Falls jemand Lust hat meinen Fork zu testen, freue ich mich über Rückmeldungen!

5 „Gefällt mir“
76

Da du ja das eeprom relativ viel benutzt für deinen erweiterten Hörbuchspeicher: Aktuell gibt es da noch einen Bug. Informationen dazu findest du in diesem Pullrequest. Eventuell kannst du das ja mal in deine Kopie vom Board Support Package mergen, testen und dort Feedback geben. Wäre jendefslls gut wenn das gemerged würde damit das auf jeden Fall im nächsten Release mit drin ist. Wann auch immer das dann sein wird.

Achja, noch ein Hinweis: Ändere nicht die Größe des eeprom. Das löscht den Bootloader. Wenn dir das passiert wird’s hässlich wenn du keinen programmer zur Hand hast. :wink: Es gibt dazu im ersten Posting in dem PR eine Warnung, diese ist aber relativ versteckt…

1 „Gefällt mir“
77

Danke für die Hinweise.
Dann muss ich das abfangen.
Verstehe ich das Richtig, dass ab einer Addressierung von über 1024 der Bootloader überschrieben wird?
Wäre sicherlich auch nicht verkehrt das im Original Sketch ab zu fangen.

78

Du kannst ja im Moment gar nicht auf Adressen über 512 zugreifen. Was ja überhaupt erstmal der Bug ist. Siehe die Tests die da hinterlegt sind. Die Bootloader Probleme bekommst du, so versteh ich das, wenn du das eeprom vergrösserst. Was wir ja eh nich tun (weil frisst ja flash).

79

Okay Danke, dann les ich mich erst mal ein.

80

So ich habe den Pullrequest in meine kopie eingefügt und kann jetzt auch über die Adresse 512, Daten lesen und schreiben.

Ich habe auf GitHub auch mein Feedback hinterlassen.

Einen Programmer hab ich hier, deswegen konnte ich bedenkenlos an die Sache ran.

Leider ist der Bugfix nichts für die breite Masse hier, deshalb muss ich meinen Fork erstmal auf die 512Byte beschneiden…
Hoffentlich wird der Pullrequest schnell übernommen.