Marco's Affenbox Fork

Es gibt ein define mit dem du die Empfindlichkeit des Lesers erhöhen kannst:

///////// NFC Gain //////////////////////////////////////////////////////
//#define NFCgain_max   // Maximale Empfindlichkeit
#define NFCgain_avg   // Mittlere Empfindlichkeit
//#define NFCgain_min   // Minimale Empfindlichkeit
//////////////////////////////////////////////////////////////////////////

aktiviere hier mal das max, statt dem avg.

Ich habe eine 1cm dicke Holzplatte vor dem Leser und ich finde das funktioniert sehr gut.
Die Karte kann man bei mir noch etwas auf der Box schieben und sie bleibt erkannt.

@raznz_snasna
ja, ohne Pause wenn Karte weg, wird die Karte neu gestartet.
Beides geht nicht.

Der Magent hält auch die Karten fest? Das muss ich mal testen.
Wäre eine sehr einfache und sehr hilfreiche Ergänzung.

Ja stimmt, in dem Sinn ist es natürlich eine Verbesserung.

Ja, das habe ich gesehen aber nicht verändert. Mit den Magneten klappt es ja wunderbar und wahrscheinlich zieht die höhere Empfindlichkeit mehr Akku.

Ja genau. Ich habe zwei dieser Magnete aufeinander an der Außenseite der Box festgeschraubt. Dadurch schließen sie bündig mit dem Schaumstoff ab. Auf den Karten habe ich dann diese Magnete festgeklebt. Dadurch flutschen die Karten von selbst an die richtige Stelle und halten auch wenn die Box auf den Kopf gestellt wird. Meine 1,5 Jährige kann damit super umgehen.

Mein eigentlicher Plan war an den Karten nur eine Beilagscheibe zu verwenden. Dazu ist der Magnet an der Box aber anscheinend nicht stark genug (obwohl der Filz weniger als 1mm dick ist). Der Vorteil daran ist aber, dass sich die Karten so von selbst „aurfräumen“, weil sie aneinander kleben.

Edit: Ein Foto (noch ohne Schaumstoffhülle) zur Veranschaulichung:

1 „Gefällt mir“

Bei Apple heißt das MagSafe :wink:

Ist aber eine interessante Idee. Muss ich mir für den nächsten Tonuino im Bekanntenkreis merken.
Bei meinen Bullis wird die Karte unter die Surfbretter geschoben, hält auch super (war nur nie so von mir gedacht :joy: aber der Sohnemann hat das so direkt von Anfang an gemacht.

Ich denke mal, dass du das kaum merken würdest mit dem Mehrverbrauch. Wir reden hier ja nicht von einem Mehrverbrauch im Wattbereich!

1 „Gefällt mir“

Ja, der Mehrverbrauch wird nicht zu spüren sein.

Ah, ich dachte die Karten würden ohne Zusatz auf dem Magnet halten, aber die Klebemagneten sind ja sehr dünn.
Solange mein 1,5 jähriger Sohn die Box immer auf den Kopf dreht, ist das eine gute Lösung.
Werde ich devinitv testen.

@Fletch Ich habe hier noch mal den Funktionsumfang aktualisiert und auch noch geplante Features mit aufgenommen, diese sind mit WIP (Work in Progress) markiert.

Ich habe sogar einen im arduino bastel kit

:heart_eyes:

, das heißt ich werde das Wochenende im Keller verbringen

1 „Gefällt mir“

Sehr gut!
Bei Fragen und Problemen, stehe ich gerne zur Verfügung.

1 „Gefällt mir“

Hi Marco,

als ich deine Beschreibung der RE Funktion gelesen habe, habe ich mich gefragt, welche Funktion bei den Kits im Vordergrund steht.

Was sagen denn die Erfahrungsträger?

Kann mir vorstellen, dass die Kits gar nicht so sehr an der Lautstärke rum spielen, sondern eher mal die Geschichte ändern und daher vermutlich mehr vor & zurück gehen.

Entsprechend scheint es mir auf den ersten Blick fast interessanter das Vor und Zurück auf die einfacherer Funktion des Drehens zu legen. Der Zusammenhang Drücken und rechtzeitig drehen scheint mir sehr Komplex und schon fast wie eine Kindersicherung. Daher hätte ich das schon eher als Lautstärkefunktion gesehen um auch ein versehentliches Verändern der Lautstärke zu verhindern.

Ggf. wäre Laut / Leise auch bei gedrücktem RE interessant. Dann ist es noch unwahrscheinlicher, dass man aus Versehen die Lautstärke auf reißt.

Und als falls das doch mal passiert, könnte ein Doppelklick auf den RE ggf. auch die Lautstärke auf Standard zurück stellen. Wenn die Kiste mal richtig brüllt, will man sie ja gewiss schnell leise bekommen.

Mein Sohn mit 1,5 hämmert gerne wahllos drauf rum, da hab ich lieber die Lautstärke auf kurzen druck. Sonst wechselt er ständig den Titel.

Aber man kann ja die Funktionen jetzt schon im Adminmenü tauschen. Das würde ich hier auch greifen lassen. Dann kann man nach gusto entscheiden.

Ich hatte schon mal gesagt, dass ich das nicht für Kindertauglich halte.
Wäre aber auf den Wunsch eingegangen, da durch meine aktuellesten anpassungen an dem Prinzip der Eingabeverarbeitung, die Umsetzung viel geringer wären.
Das ist was für „Kinder“ die damit umgehen könne oder für Aufbauten die sehr klein sind.

Ein Feedback durch eine LED wäre hier sicher auch nicht verkehrt.

Leider muss man sich hier auf ein Layout festlegen und kann es nicht per defines oder zur Laufzeit anpassen, zu groß ist hier die Varainz an kombinationen. Bei der Fernbedienung oder den Analogen Inputs ist das viel einfacher.

Wie ist das, dein überarbeiteter Fork. Läuft der in der Loop konsequent durch? In dem Original sind diverse stellen, insbesondere im Admin Menü, an denen er in einer Schleife wartet. Auch die ganzen Delays sind mir eine Dorn im Auge. Hast du das zufällig bereinigt?

Delays sind mit dem DF Player leider unvermeidbar und müssen mit wachsender SD Karte teilweise vergrößert werden.
Man muss oft lange auf das Ding warten und kann währenddessen nichts anderes sinnvolles tun. Teilweise prellt der auch. NextTrack feuert teilweise 2-3 mal.
Anspielen von Titeln dauert, genauso wie das pausieren.

Das Adminmenü ist bei mir Grundlegend gleich geblieben.

Was meinst du damit ob die loop durchläuft? Ob ich in Schleifen hängen bleibe?

Hast du ein Beispiel für besonders störende Stellen? Ich weiß schon gar nicht mehr was ich alles im Detail angepasst habe.

Ja, ich meine das Hängen in Schleifen (delay ist ja letztlich auch nur ne Schleife).

Denn wenn du Zuverlässig zwischen Klick, Doppelklick, langem, oder sehr langem Tastendruck unterscheiden willst (wie z.B. AceButtons), dann ist es gewiss nicht Sachdienlich, wenn man in der Mainloop nicht halbwegs reproduzierbar die DI Eingänge abfragen kann.
Da wird aus zwei Tastendrücken ganz schnell ein Longpressed, weil eine delay beim Playeraufruf dafür gesorgt hat, dass der ReadButtons den Zustand dazwischen gar nicht sehen konnte. Das zwingt einen dann in Interruptroutinen. Und eigentlich ist für so ein paar Tasten eine Interruptbehandlung doch unnötig. Vorausgesetzt, der Rest vom Code legt die Bearbeitung nicht lahm.
Daher sehne ich mich beim Adminmenü nach einem sauberen Zustandsautomaten. Nur bevor ich jetzt loslege, und du pushed heute Nacht dein neues Rundumsorglospaket ;o), wollte ich doch erstmal fragen.

Leider nicht.

Aber @thorsten ist da dran, er hat ja schon etwas gespoilert.

In 2-3h Abends ab 21:00 ist einfach kein High End Code zu bewältigen.

vieleicht muss ich mal bei Gelegenheit meinen Code nach delays und schleifen durchforsten.

1 „Gefällt mir“

Arbeitet ihr beiden zusammen an der neuen Version? Du hast weiter oben schon größere Umbauten erwähnt die in eine sehr ähnliche Richtung gehen, wie das was Thorsten erwähnt hatte. Ich nehme an, Thorsten wird ähnliche Lösungen suchen. Wäre ja doch irgendwie zeitschonender, wenn jeder einen Teil macht, oder? Bevor jeder sein eigenes Süppchen kocht?

Hab übrigens schon mal nach Schleifen gesucht. Es sind viele. Und da ich das Admin Menü noch nicht verstanden habe, traue ich mich da nicht so richtig ran. Das ist schon nen dicker Brocken.

Das Admin menü ist quasi ein loop für sich mit mehreren unter loops für jeden Menüpunkt.
Ich habe das mit Enums etwas leserlicher gemacht.
Für die Sprachführung gibt es das voiceMenu, das wiederum in einer Schleife arbeitet.

Schleife in Schleife in Schleife. Leider nicht ideal. Ich arbeite schon seit April daran und hab mich daran gewöhnt. Fehlersuch ist leider ein Horror.
Kämpfe gerade mit einem komischen Verhalten, das sich kaum bis gar nicht Debuggen lässt.

Ich wollten schon ein Klasse schnitzen. Als Gerüst für einen einfachen Zustandsautomaten.

Eine Methode: onEnter
Hier wird alles gemacht, was den Zustand vorbereitet. Z.B. die einleitende Textansage. Die wird wie eine Loop zyklisch durchlaufen. Sie gibt solange false zurück, solange z.B. die Ansage noch läuft etc. Sobald sie fertig ist, gibt sie true zurück.

Ein Handler in der Mainloop ruft dann
currentState der selben Klasseninstanz auf.

Hier warten wir auf Eingaben, verwalten ggf. einen Timeout und arbeiten die Weiterschaltbedingungen ab. Er gibt eine Pointer auf den nächsten Zustand zurück. Also solange er läuft, den der eigenen Klasseninstanz. Sobald der Zustand verlassen werden soll, gibt er den Pointer auf die Klasse des nächsten Status zurück.

Der Handler in der Mainloop ruft sobald sich der Pointer ändert noch die onExit Methode des alten Zustandes auf.
Auch die liefert false, bis sie fertig ist und dann true.

Dann ruft der Handler den nun aktuellen Pointer auf, der genau so reagiert wie eben beschrieben. So kann man sich von einem Zustand zum anderen hangeln.

Main Problem ist nur. Ich raffe diese Admin Menü nicht, und weiß nicht, was ich in die Zustände füllen muss. Mir fehlt da echt die Orientierung.

Wenn du mir genaue Stellen nennst, die du im Admin Menü nicht verstehst, kann ich dir sicher weiter helfen.
Aber schriftlich das Gesamte Ding zu erklären word schwer.

Das dann aber am besten per PN

Also diese Arduino IDE ist ja ein graus!
Ich hab jetzt 2h nach einem Fehler gesuchtm der mir ein Byte einer Variablen überschrieben hat.
Um fest zu stellen das ich einen groben Fehler im setzen eines Arrays gemacht habe.
Das array wurde mit 2 Feldern erstellt und ich habe Versucht Index 2 zu beschreiben, den es nicht gibt.
Anstatt aber einen Syntax Error zu werfen, überschreibt er einfach die Variable an der Adresse…

Er hat die RFID Tags nicht mehr erkannt weil der key überschrieben wurde. Das muss man erstmal finden…