Git ist bereits eingerichtet.
In meinem Fork (lokal) habe ich die Firmware bereits grossteils von „quick and dirty“ auf „clean“ umgebaut. Dabei weitere Optimierungen - insbesondere in der Auto-Kalibrierung - vorgenommen.
Jetzt die Frage der Fragen:
Wer wartet schon darauf und ist hardwaremäßig (wann) „ready for fieldtest“?
Firmware ist fertig!
Es ist lediglich ein #define zu aktivieren.
Kalibrierung läuft vollautomatisch.
Via WebGUI Info können die Werte angesehen werden und ggf. die #defines optimiert werden.
Eine fehlerhafte Erstkalibrierung (z.B. wenn ein MagnetTag während der NullFieldValue Ermittlung aufliegt) kann über einen WebRequest /inithalleffectsensor einfach wiederholt werden.
Bei jedem Neustart erfolgt eine Autokalibrierung des NullFieldValues sofern kein MagnetTag aufliegt.
warte auf PN von Interessierten!
Nach erster externen erfolgreicher Installation vom erweiterten Master erfolgt die Dokumentation im Forum und Freigabe an Torsten zur Einbindung in seinen Master Branch.
VG Niko
Sehr cool. Ich wäre ein Testkandidat. Halleffektsensor und alles andere liegt bereit, habe den Sensor aber noch nicht verkabelt. Kannst du mir einen Link zu deinem Fork geben? Vllt komme ich am Wochende dazu das mal auszuprobieren.
Habe mir soeben den PN5180 in mein Projekt (D32 pro) aufgenommen, um auch für diesen Reader die „DualTagFunction“ zu implementieren. Für mich hatte ich das ja bereits für den Reader RC522 erfolgreich vorgenommen.
Nun zeigen sich bei mir jedoch mit dem PN5180 bereits OHNE meine Änderungen enorme Probleme mit diesem Reader. Ich erhalte sporadisch verfälschte UIDs bei ein und derselben Karte.
Hier das RS232 LOG:
Die korrekte UID wäre 4d-7e-94-b5 (077126148181)
aber es kommen zwischendurch immer wieder UIDs mit verfälschten 1. bzw. auch 2. Byte
RFID-Karte erkannt: (ISO-15693) ID: 4d-7e-94-b5
RFID-Karte empfangen: 077126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 077126148181 NOT_FOUND
RFID-Karte ist im NVS nicht hinterlegt.
RFID-Karte erkannt: (ISO-15693) ID: 4d-7e-94-b5
RFID-Karte empfangen: 077126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 077126148181 NOT_FOUND
RFID-Karte ist im NVS nicht hinterlegt.
RFID-Karte erkannt: (ISO-15693) ID: 04-e0-94-b5
RFID-Karte empfangen: 004224148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 004224148181 NOT_FOUND
RFID-Karte ist im NVS nicht hinterlegt.
RFID-Karte erkannt: (ISO-15693) ID: 4d-7e-94-b5
RFID-Karte empfangen: 077126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 077126148181 NOT_FOUND
RFID-Karte ist im NVS nicht hinterlegt.
RFID-Karte erkannt: (ISO-15693) ID: b5-7e-94-b5
RFID-Karte empfangen: 181126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 181126148181 NOT_FOUND
RFID-Karte erkannt: (ISO-15693) ID: 4d-7e-94-b5
RFID-Karte empfangen: 077126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 077126148181 NOT_FOUND
RFID-Karte erkannt: (ISO-15693) ID: 4d-7e-94-b5
RFID-Karte empfangen: 077126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 077126148181 NOT_FOUND
RFID-Karte erkannt: (ISO-15693) ID: 6a-7e-94-b5
RFID-Karte empfangen: 106126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 106126148181 NOT_FOUND
RFID-Karte ist im NVS nicht hinterlegt.
RFID-Karte erkannt: (ISO-15693) ID: 4d-7e-94-b5
RFID-Karte empfangen: 077126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 077126148181 NOT_FOUND
RFID-Karte erkannt: (ISO-15693) ID: 4d-7e-94-b5
RFID-Karte empfangen: 077126148181
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 077126148181 NOT_FOUND
Ich habe sichergestellt, dass keine andere Karte in der Nähe ist.
Der Aufbau ist mittel Breadboard. Die Kabel sollten stabil stecken.
Nach mehrfachen Versuchen passiert es dann auch, dass gar keine Reaktion mehr auf Vorhalten einer Karte erfolgt. Nach Reset funktioniert es wieder.
Hat jemand eine Idee, woran das liegen könnte?
PN5180 ist wie folgt angeschlossen:
+5v und 3.3V beide auf 3.3V
GND auf GND
folgende GPIOs:
// RFID (via SPI)
#define RST_PIN 99 // Used as dummy for RC522
#define RFID_CS 21 // GPIO for chip select (RFID)
#define RFID_MOSI 23 // GPIO for master out slave in (RFID)
#define RFID_MISO 19 // GPIO for master in slave out (RFID)
#define RFID_SCK 18 // GPIO for clock-signal (RFID)
#ifdef RFID_READER_TYPE_PN5180
#define RFID_BUSY 33 // PN5180 BUSY PIN
#define RFID_RST 22 // PN5180 RESET PIN
#define RFID_IRQ 99 // Needs to be adjusted to 106 if LPCD-mode is desired!
#endif
Vielen Dank für Hinweise im Voaus!
EDIT:
PN5180 Firmware: 3.5
Problem gelöst:
Es lag ganz offensichtlich an der Versorgungsspannung.
Reader 5V und 3.3V an 3.3V des D32 pro angeschlossen.
Mir ist auch aufgefallen, dass der MosFET für Power OFF im DeepSleep nicht mehr korrekt arbeitete.
Ich habe zur Kontrolle eine LED am Ausgang des MosFETs angeschlossen und die hatte ebenfalls zyklische sporadische Aussetzer, d.hdiese flackerte.
Nun habe ich die 5V des Readers wirklich an USB 5V gelegt und nur mehr die 3.3V an 3.3V des D32 pro
und damit ist die LED wieder stabil und keine Fehllesungen mehr.
Eine mögliche Erklärung für Dein Phänomen:
Die 5V Schiene bedient den HF/RF-Teil, der 3.3V Teil den PN5180 Chip & die Logik. Es könnte möglich sein das Dein Metall-Gerödel im RF-Feld den Leser auf einen sehr hohen Strom eingeregelt hat und dann auch die Spannung ein wenig zusammengebrochen ist (Flackern der LED).
Im Normalfall funktioniert der PN5180 auf der 5V Schiene auch mit 3.3V, aber die Lesereichweite leidet darunter. Empfehlung: Den 5V PIN auch an 5V anzuschließen falls verfügbar. Da bist Du warscheinlich in einen Grenzfall reingelaufen…
An Interessenten für die Dual-Tag-Lösung habe ich heute ein Fork des aktuellen master gezogen und die Ergänzungen für den HallEffektSensor hinzugefügt.
Das richtet sich an alle, die das vorab schon testen bzw. verwenden wollen.
Dazu folgt hier eine kurze Doku:
Siehe auch vorherige Beiträge in diesem Thread.
Hardware:
Es wird ein analoger Halleffektsensor benötigt:
SS49E
Dieser hat 3 Anschlüsse:
1: Vdd => +3.3V
2: Gnd => GND
3: Out (Analog) => freien GPIO (analogRead) z.B: 34
Hockeytag - Parts und Assembling:
Dabei ist folgendes zu beachten:
Firmware:
Dieses Feature ist seit 23.01.2023 im offiziellen Master integriert. Vielen Dank an @biologist!
In „settings.ini“ folgende Zeile aktivieren (auskommentieren):
#define HALLEFFECT_SENSOR_ENABLE // When enabled, also configure #define HallEffectSensor_PIN in "HallEffectSensor.h". (https://forum.espuino.de/t/magnetische-hockey-tags/1449/35)
und in „HallEffectSensor.h“:
#define HallEffectSensor_PIN 34 // GPIO (ADC)
Anbei noch eine Vorabanleitung (WebGUI, Logeinträge, Trouble-shooting)
VorabDoku ESPuino HallEffectSensor_v2.pdf (228,9 KB)
Aktuell getestet mit „Mini Board“ und PN5180 Reader:
Sollte ich was vergessen haben, einfach hier posten.
VG & Viel Spaß
So, ich habe den Hallsensor-support eben in dem Master integriert.
Hab’s jetzt so integriert, wie die anderen Module auch integriert sind. Support bietet @Niko 
.
Falls jemand einen 3D Drucker besitzt kann man die Spacer auch einfach Drucken. Nicht jeder hat Zugang zu einem Laser. 
Welche RFID-Tags verwendest du und Bezugsquelle?
Mir gefällt, dass die größer sind und der Magnet damit den Antennenbereich nicht überdeckt!
Mit den 12mm Magneten wird es interessant, welche Differenzwerte du mit und ohne Magnet erreichst. Sollten, wie in der Doku beschrieben, mindestens 60 sein besser über 100.
Freu mich auf Feedback
Die Tags sind NXP ICODE SLIX-L wie sie auch bei anderen bekannten Musikboxen verwendet werden.
Gibt es bei ebay-kleinanzeigen
Stichwort: RFIDfriend 
Sind die mit LPCD kompatibel?
@HansKlaus Nein, leider bisher nicht.
Das sind ISO-18693 Tags, für das Aufwecken können bisher nur Standard Karten im ISO-14443 Format verwendet werden. Ich arbeite dazu aber an einer Lösung…
Was benutzt ihr so als Metallteil im Gehäuse, als Gegenstück zu den Magneten in den Tags? Ich hatte ursprünglich die Idee Unterlegscheiben zu benutzen. Das hat sich aber als unschön herausgestellt, weil die Tags durch das Loch in der Unterlegscheibe sich nicht mittig positionieren.
Das Teil muss ja recht schmal sein.
Jetzt plane ich ein schmales Stück des Gewindes einer M10-Schraube abzuschneiden und zu verwenden. Aber natürlich musste erst mal mein Winkelschleifer den Geist auf geben (Ersatzteil kommt hoffentlich morgen).
Also für die Dualfunktion ist überhaupt kein Gegenstück notwendig. Wenn aber der Tag magnetisch ins Zentrum gezogen und dort leicht gehalten werden soll (z. B. bei Pause, wenn Tag entfernt wird) , dann habe ich eine Mutter (M6 oder M8) verwendet.
Ich wundere mich, dass obwohl ich ein volles (also ohne Loch), rundes Metallteil benutze, der magnetische Tag nicht zur Mitte „fluppt“ sondern eher am Rand des Metallteils. Ich bin kein Physiker, aber iwie hätte ich erwartet, dass es sich zentriert. Jemand ne Idee dazu?
Herzlichen Dank noch für die Empfehlung des NXP ICODE SLIX-L Tags. Damit ist bei meinem Gehäuse auch mit einem 15 mm Magnet eine zuverlässige Erkennung gegeben. Mit den kleinen Tags war das nicht der Fall. Und ein 10 mm Magnet wäre in meinem Fall zu schwach. Von LPCD hab ich mich eh verabschiedet, ist zu sehr nice to have.
Vllt wäre so ein Stanzteil die Lösung: 13.7€ |Runde Leder Stanze Werkzeug Loch Hohl Punch Cutter Set Bequem Praktische Loch Puncher Für DIY Verarbeitung Kunststoff Gummi| | - AliExpress 40 mm ist da dabei.
Hab ich mal bestellt, weil das Ausschneiden eine Hürde ist, die einen dann schnell vom schön machen abhält.
Warum so kompliziert?
Runde Etiketten 40 mm Durchmesser 600 Markierungspunkte/Sticker selbstklebend blanko weiß 40mm rund auf 25 DIN A4 Bogen https://amzn.eu/d/ijNCHXc
Zum einen muss man sich da eine exakte Druckvorlage bauen und hat den hassle mit der Ausrichtung/der Präzision, zum anderen haben wir keinen Drucker, weshalb ich das entweder extern drucken lasse oder einen Fotodienst nehme.
