@Jonas Ja und auch eingebunden.
Ok, da fehlt ein
#include „PN5180_Firmware.h“
am besten nach dem
#include „Firmware.h“
Ist etwas Schade das der Code in dem Github leicht defekt ist.
In diesem Github wurde es behoben: GitHub - simsasaile/PN5180_Updater_ESP32 at patch-1
1 „Gefällt mir“
aaaah jetzt macht es sinn. Danke !!!
Gute Nacht!
Genau, das ist von mir, hatte das Problem auch, deshalb hab ich den Patch dort als merge request eingereicht. Scheint leider noch nicht im master angekommen zu sein.
Ich hänge grade vor einem sd_mmc problem.
> [E][SD_MMC.cpp:85] begin(): Failed to initialize the card (263). Make sure SD card lines have
> pull-up resistors in place.
Den 10k ohm widerstand habe ich entfernt. Gibt es sonst etwas was ich testen kann?
- Schaue, dass die GPIOs 2, 14 und 15 nicht anderweitig verwendet werden
- SD_MMC muss in der settings.h aktiviert werden
in settings.h hatte ich bereits #define SD_MMC_1BIT_MODE auskommentiert.
Folgender Eintrag muss geändert werden (was auch immer VP bedeutet :D)
#define PREVIOUS_BUTTON 2
muss auf
#define PREVIOUS_BUTTON 36
Danke es funktioniert jetzt! Speiel mal ein wenig mit dem LPCD rum.
1 „Gefällt mir“
VN: GPIO39
VP: GPIO36
Ich kann’s mir auch nicht merken, was welcher ist 
Aber z.B. hier steht sowas: ESP32 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials
Interessant das gleiche problem mit dem audio habe ich auch. Habe es jetzt mit Headphone_adjust_enable probiert und auch wenn ich nun mono wieder deaktiviert habe springt die lautstärke permanent von maximum auf minimum.
Es hat geholfen wie im Bild ein Pull Up Widerstand einzulöten.
@biologist
Was mich jedoch wundert ist das die Erkennung nicht wirklich besser ist. Also es funktioniert wenn das Gerät aktiv nach neuen Karten sucht, aber mitten im Hörbuch komischerweise nicht oft.
Kann das was mit meinen Kabeln zu tun haben ? die sind vielleicht 15cm lang.
EDIT: Verrückt, ich habe nun einen anderen angelötet, zwar mit FW Version 3.5 aber mit kürzeren kabeln. Funktioniert allerdings deutlich besser. Probiere es nach der Arbeit morgen nochmal ein wenig.
Also wo es tatsächlich einen Bug gibt: Man legt eine Karte 2mal hintereinander ohne Neustart auf. Das funktioniert beim PN5180 im Task nicht, ohne Task allerdings schon. Warum auch immer. Legt man dazwischen eine andere Karte auf, dann geht’s wieder. Das konnte bisher nicht umgestellt werden, weil die Pollzeit des PN5180 zu lange war. Mit der State-Machine, die @tuniii eingebaut hat, habe ich es noch nicht ausprobiert, ihn aus dem Task zu nehmen.
Meinst du das?
@biologist
Das ist mir auch schon aufgefallen. Nein ich meinte damit das das Ding auf der aktuellsten firmware und langen kabeln sehr unresponsive ist. Also manchmal erkennt es eine Karte und manchmal nicht. Habe alle Kabel geprüft und alle Lötstellen nochmal nachgelötet gehabt.
Habe jetzt die Kabellänge halbiert (auf 7,5 cm) und es funktioniert tatsächlich sehr viel besser. Wundert mich, da das ja eigentlich ein digitales Signal sein sollte. Werde morgen nach der Arbeit nochmal ein bisschen daran frickeln 
Das ist extra so implementiert. Soll das nicht so sein? Wenn eine Karte zwei mal hintereinander kommt, dann wird es verworfen und die State Machine geht wieder an den Anfang. Ich hab das von der vorherigen Implementierung so übernommen. Bei mir geht die State Machine auf Reset, zuvor wurde für die Task-For-Schleife ein continue gemacht. Aber das wäre dann auch schnell behoben.
// check for different card id
if (memcmp((const void *)cardId, (const void *)lastCardId, sizeof(cardId)) == 0) {
// reset state machine
stateMachine = RFID_PN5180_NFC14443_STATE_RESET;
return;
}
memcpy(lastCardId, cardId, cardIdSize);
Diese Stelle müsste man löschen und die Variable lastCardId entfernen.
Ich dachte das sei zum Entprellen, aber beim Anlernen und Testen einer Karte macht das dann wirklich keinen Sinn…
Nein, das soll nicht so sein. RC522 funktioniert auch nicht so. Die gleiche Karte soll auch mehrmals hintereinander erkannt werden können. Sonst isses z.B. doof, wenn du eine Karte anlernst und die im Anschluss testen willst. Das geht dann ohne Zwischenauflegen einer zweiten Karte nicht. Oder du hast eine Modifikationskarte aufgelegt, die du gerne wieder zurücknehmen möchtest. Legt man normalerweise einfach ein zweites Mal auf.
Ich hatte mit @tueddy mal drüber gesprochen, er hat PN5180 damals implementiert. Bei ihm lief das aber im Task im ESPuino halt nicht. Und genau das habe ich auch beobachtet.
Ich hab den Punkt schon länger im Hinterkopf. Aber ich habe aktuell leider einfach nicht Zeit, das alles immer zu fixen… 
Ich habe einen PR erstellt.
1 „Gefällt mir“
Perfekt. Klappt!
Danke.
Hallo zusammen,
ich habe die Platine („Lolin32 mit SD (SD_MMC) und PN5180 als RFID-Leser“) nun in der Box meines Sohnes in Betrieb genommen. Die höhere Empfindlichkeit des PN5180 macht sich sehr gut, da die Box aus recht dickem Multiplex besteht (ich glaube 6 mm) und der MFRC522 oft nicht sofort reagierte (und ich keine Lust hatte mit der Oberfräse Material für den Leser rauszufräsen).
Zwei Fragen habe ich:
- Wenn ich die RFID Karte auf der Box liegen lasse, dann läuft die Musik für einige Minuten (gefühlt so 3 min) einwandfrei, und startet dann von vorne. Das Verhalten tritt sowohl mit einem alten Softwarestand (Mitte April), also auch mit dem aktuellen Master sowie dem Refactoring Branch auf. Das Problem scheint nicht aufzutreten, wenn ich die Karte nach dem Erkennen wieder entferne. (Edit: Die Box scheint nicht neu zu starten, sondern die Karte wird ein weiteres mal erkannt, und erwirkt damit ein erneutes Abspielen des ganzen Ordners.)
- Das Aufwecken mittels RFID Karte klappt mit dem Master Branch, aber nicht mit dem Refactoring Branch. Ist das ein bekanntes Problem, oder stimmt bei mir etwas nicht?
Viele Grüße
Johannes
Ich wundere mich . Mein RC522 funktioniert immer noch wenn ich die Box unter meine Schreibtischplatte halte , das sind insgesamt 5mm Frontplatte Sperrholz + 25 mm Kiefer massiv .
Also auf Basis meiner ganzen Tests kann ich auf jeden Fall sagen, dass der PN5180 hinsichtlich seiner Reichweite dem 522 deutlich überlegen ist. Er kostet halt mehr, er braucht mehr GPIOs und man kriegt ihn halt nur in China. Normalerweise teste ich ja immer auf irgendwelchen PCBs und nicht in geschlossenen Gehäusen. Jedoch haben meine beiden Kinder ESPuinos hier stehen. Und da ist es jetzt so, dass der ESPuino meines Sohnemanns deutlich größer ist als der ESPuino meiner Tochter. Und Letztgenanntes hatte halt zur Folge, dass es echt eng geworden ist im Gehäuse und die Ordnung ein bisschen gelitten hat. Und während der RC522 beim Sohnemann noch ok performt hat, war das im kleineren Gehäuse echt schlecht. Mit dem PN5180 konnte ich das retten. Ich glaube (wissen tue ich es nicht), dass es dem PN5180 deutlich weniger ausmacht, wenn irgendwelcher Metallkram in der Nähe ist. Von daher denke ich, dass es von der Holzdicke alleine nicht so ultimativ abhängt.
- Ich muss zugeben, dass ich ne Karte nie habe so lange liegen lassen. Muss ich mal testen.
- Hier muss ich mir wohl mal ein Testsystem bauen. Ich habe aktuell keines hier und es ergo auch noch nicht getestet.
@jpellenz Meine Vermutung ist, dass es zwischendrin mal zu einem Event kommt, wo die Karte kurz nicht erkannt wird. Und das führt dann dazu, dass im nächsten Zyklus ein Neuauflegen interpretiert wird. Vermutlich muss ich einen Zeitstempel mitspeichern, so dass ich solch kurze Events einfach „übersehen“ kann.
Bei meinem offenen Aufbau hier kann ich es auf jeden Fall nicht nachstellen, aber da liegt die Karte halt auch direkt auf dem Reader drauf. Aber auch im ESPuino meiner Tochter lässt sich das nicht nachstellen.
Mach’ bitte mal Folgendes:
Dort unterhalb der markierten Zeile (innerhalb des for-Anweisungsblockes!) z.B. sowas eintragen:
Serial.println("No card detected!");
So lange keine Karte aufgelegt wird, wird dieses Event ganz oft geworfen. Wenn eine Karte aufgelegt wird, dann nicht mehr. Und die Frage ist jetzt, ob dieses Event zwischendrin mal geworfen wird, wenn die Karte noch aufliegt.
Hallo Torsten,
Du hast recht - das scheint die Ursache zu sein - siehe unten. Immer in Paketen von vier Zeilen kommt die Meldung „***** No card detected! *****“
Dahinter habe ich noch den Zeitstempel ausgegeben (millis()).
Ich weiß, es gab schon mal die Diskussion über den Umgang mit vom System gemeldeten identischen Karten-Nummern. Ich glaube je nach Kontext ist ein unterschiedlicher Umgang sinnvoll. Also beim Anlernen ist ein zweites Mal die gleiche Kartennummer sinnvoll (für den Test der Karte); beim Abspielen aber eher nicht (wie hier in dem Fall).
Viele Grüße und danke für den Hinweis schon mal.
Viele Grüße
Johannes
Rebooting...
Restored maximum inactivity-time from NVS.: 10
Restoring initial LED-brightness from NVS: 16
Restored LED-brightness for nightmode from NVS: 2
_____ ____ ____ _
| ____| / ___| | _ \ _ _ (_) _ __ ___
| _| \__ \ | |_) | | | | | | | | '_ \ / _ \
| |___ ___) | | __/ | |_| | | | | | | | | (_) |
|_____| |____/ |_| \__,_| |_| |_| |_| \___/
Rfid-controlled musicplayer
Rev 20210630-2
Wakeup was not caused by deep sleep: 0
...
Restored lower voltage-level for Neopixel-display from NVS: 3.00 V
Restored upper voltage-level for Neopixel-display from NVS: 4.20 V
Restored battery-voltage-level for warning via Neopixel from NVS: 3.40 V
Restored interval of battery-measurement or Neopixel-display from NVS: 10 Minuten
Restored hostname from NVS: espuino3
.Current IP: 192.168.178.185
Free heap after setup: 127356
PSRAM: 0 bytes
Flash-size: 4194304 bytes
Firmware version=4.1
RFID-tags can now be applied...
Trying to connect to MQTT-broker ...
Try to connect to MQTT-server with user und password
New volume received via queue: 3
MQTT-connection established.
RFID-tag detected: 15-b3-33-28
RFID-tag received: 021179051040
Playlist-generation: cached
Free memory: 91624
Number of valid files: 21
Mode: all tracks (in alph. order) of directory '/Music/Compilations/albumtitle'
New playlist received with 21 track(s)
Free heap: 90588
info : PSRAM not found, inputBufferSize: 6399 bytes
info : buffers freed, free Heap: 82572 bytes
info : Reading file: "..."
...
info : Audio-Length: 2712266
info : syncword found at pos 0
info : Channels: 2
info : SampleRate: 44100
info : BitsPerSample: 16
info : BitRate: 192000
MQTT-message received: [Topic: Cmnd/ESPuino/Loudness] [Command: 3]
New volume received via queue: 3
MQTT-message received: [Topic: Cmnd/ESPuino/LedBrightness] [Command: 16]
MQTT-message received: [Topic: Cmnd/ESPuino/LedBrightness] [Command: 0]
MQTT-message received: [Topic: Cmnd/ESPuino/LedBrightness] [Command: 16]
Current battery-voltage: 3.95 V
***** No card detected! ***** at 29595
***** No card detected! ***** at 29595
***** No card detected! ***** at 29595
***** No card detected! ***** at 29597
RFID-tag detected: 15-b3-33-28
RFID-tag received: 021179051040
Playlist-generation: cached
Free memory: 65628
Releasing memory of old playlist.
Free memory after cleaning: 67980
Number of valid files: 21
Mode: all tracks (in alph. order) of directory '/Music/Compilations/albumtitle'
New playlist received with 21 track(s)
Free heap: 67436
info : buffers freed, free Heap: 90788 bytes
info : Reading file: "..."
...
info : Audio-Length: 2712266
info : syncword found at pos 0
info : Channels: 2
info : SampleRate: 44100
info : BitsPerSample: 16
info : BitRate: 192000
***** No card detected! ***** at 43690
***** No card detected! ***** at 43690
***** No card detected! ***** at 43690
***** No card detected! ***** at 43692
RFID-tag detected: 15-b3-33-28
RFID-tag received: 021179051040
Playlist-generation: cached
Free memory: 65536
Releasing memory of old playlist.
Free memory after cleaning: 67876
Number of valid files: 21
Mode: all tracks (in alph. order) of directory '/Music/Compilations/albumtitle'
New playlist received with 21 track(s)
Free heap: 67320
info : buffers freed, free Heap: 90684 bytes
info : Reading file: "..."
...
info : Audio-Length: 2712266
info : syncword found at pos 0
info : Channels: 2
info : SampleRate: 44100
info : BitsPerSample: 16
info : BitRate: 192000
```