(Hab die Idee noch etwas genauer gefasst und neu formuliert.)
Deine Variante 2 würde ich noch etwas verfeinern und zwei Fälle beim Auflegen unterscheiden:
UID ist bekannt: Einfach wie gewohnt abspielen. Hall Sensor wird gar nicht genutzt.
UID ist unbekannt: Es wird, sagen wir mal, max. 5 Sekunden versucht, die Polarität zu bestimmten. Sollte das eindeutig funktionieren, wird die UID intern angepasst. Ich schlage vor, das erste Byte zu inkrementieren. +1 für Nord, +2 für Süd (modulo 16). Die angepasste ID kann dann wieder nachgeschlagen werden und ggf. abgespielt.
Auf diese Weise gibt es keine unnötigen Wartezeiten und auch kein kurzes Abspielen von ggf. falschen Inhalten.
(Alter Post: Sobald ein Tag aufgelegt wird, wird der Hall Sensor laufend ausgelesen bis zu einer Grenzzeit, sagen wir 5 Sekunden. Wiedergabe kann bereits gestartet werden, falls die UID bekannt ist. Falls bis dahin keine eindeutige Orientierung erkenntlich ist, haben wir wohl einen normalen Tag, alles easy.
Sollte in der Zeit doch ein Magnetfeld safe erkannt werden, würde ich das erste Byte der UID (quasi Hersteller-Byte) um 1 (Nord) respektive 2 (Süd) inkrementieren mod 16. Dann die Wiedergabe starten. Die originale UID ohne Inkrementierung sollte dann gar nicht registriert sein im ESPuino.
Damit stellt man sicher, dass nicht einen kurzen Moment die falsche Seite abgespielt wird und es geht bei normalen Tags ohne Wartezeit los.)
Gerade einen kurzen Test mit meiner Box gemacht: Nur mit einer kleinen Eisenscheibe statt Magnet im Gehäuse halten die Tags nicht. Also müsste ggf. ein größerer oder kräftigerer Magnet in so einen Tag rein…
Meine Ankündigung habe ich nun gestern in die Tat umgesetzt.
Damit kann ich euch ermutigen, dass meine Idee mit dem Halleffektsensor in der Praxis recht einfach machbar ist.
Ich weise in den Bildbeiträgen auch darauf hin, auf was besonders zu achten ist.
Am Schluss seht ihr ein Video mit der neuen Funktionalität „Hockey-Dualfunction-Tag“.
Hardwareänderung:
Zuerst das Innenleben meines ESPuinos mit dem Einbau des Hallsensors auf dem RFID-Readers:
Eine M10 Mutter - In die Meitte den HalleffektSensor mit Heißklebepistole fixiert.
Anschluss: 3 Kabel: GND, 3.3V, IO32
Softwareänderung:
Ein paar Zeilen sind anzupassen.
Bezüglich Manipulation der UID habe ich gerne die Idee von sonovice mit Inkrementierung des 4. Bytes um 1 oder 2 je nach Magnetpol
Wenn Interesse zum Nachbau besteht, dokumentiere ich das gerne genauer.
Der RFID-Tag muss möglichst an den äußeren Rand platziert werden.
Hintergrund:
Ist bei mir deshalb wichtig, da ich 15x3mm Neodym Magnete verwende und dieser den Tag komplett abschirmen würde.
Bei 10mm war das kein Problem, den Tag zentriert zu setzen.
10mm waren aber schon grenzwertig. Da muss der Tag genau auf den Leser gesetzt werden, d.h. man müsste schon fast kleine Begrenzungen aufkleben.
Deshalb hab ich mich dann für die 15mm entschieden. Da läuft das Ganze problemlos.
Zwischen Tag und Magnet soll das Trägermaterial der Tags als Isolation und Abstand nicht entfernt werden.
Sehr cool, gerne genauer dokumentieren.
Vllt kann die Softwareänderung per PR auch in den Hauptzweig?
Interessanter Punkt, das mit dem seitlichen Positionieren des Tags.
Muss man für den Halleffektsensor irgendwas beachten oder kann man den nächstbesten nehmen?
Wenn ich das richtig verstehe, dann kann man mit dem Expanderboard auch einfach Pin 32 von der EXT-Leiste benutzen, wenn jp5 auf 2-3 gebrückt ist, was bei mir auch schon der Fall ist. Korrekt, @biologist?
Es gibt analoge und digitale (mit SchmittTrigger) und da mit und ohne Latch.
Bei denen mit Digitalausgang unbedingt ohne Latch, sonst bekommt man unvorhersehbare Ergebnisse bei normalen Tags ohne Magnet.
Ich habe für ein anderes Projekt bereits einen analogen zur Hand gehabt mit dem sich das gut umsetzen ließ. Ist auch preislich interessant. Wenn es vergleichbare gibt mit höherer Empfindlichkeit dann ist das kein Nachteil. Weiter oben habe ich den Typ den ich verwende bereits erwähnt: SS49E
I’m weiteren Verlauf auch zum Thema Sensoren mit digitalem Ausgang.
Kann gerne die Implementierung vornehmen sodass dieses Feature wie gewohnt mit #defines in „settings“ aktiviert und in "settings-env… " das Port für den analog input konfiguriert werden. Zudem ist mit http get Befehl die automatische Kalibrierung auszulösen, die die optimalen, sicheren Schaltschwellen für beste Empfindlichkeit ermittelt und im NVS ablegt. Damit muss lediglich 2 #defines aktiviert werden und die Kalibrierung aufgerufen werden. Im Web-GUI können die Werte unter Infos ausgelesen bzw. Beobachtet werden.
@biologist
Ich würde mir den aktuellen Master via git Desktop ziehen und die Änderungen vornehmen. Zum Thema PullRequest fehlen mir noch die notwendigen Infos Schritte. Deine Meinung auch gerne via PN. LG
Also es braucht auf jeden Fall eine exakte Beschreibung, was da wie und wo gemacht werden muss beim Setup. Man kann in den Settings zudem auch auf so nen Thread wie hier verweisen - das habe ich schon öfter gemacht. Aber grundsätzlich finde ich es immer gut, wenn man eine eigene Seite hat, auf der das Feature mal richtig beschrieben wird. Z.B. sowas: Neues Feature: Bluetooth Kopfhörer.
Von meiner Seite werde ich das Ganze jedoch nicht testen/supporten - das müsst dann ihr machen . Also das ist jetzt nicht bös’ gemeint, aber ich kann das nicht alles testen und habe dafür auch keinen Testaufbau.
Aber ich find’s cool euer Feature!
PR ist eigentlich nicht notwendig. Ich kann mir per Cherry-Picking auch einen Commit holen aus deinem Repository. Üblicherweise wird das in einem Feature-Branch gemacht, aber das ist mir letztlich egal. Was ich nur nicht will sind irgendwie zehn Commits oder so .
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
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.
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
Der RFID-Tag muss möglichst an den äußeren Rand platziert werden.
Hintergrund:
Ist bei mir deshalb wichtig, da ich 15x3mm Neodym Magnete verwende und dieser den Tag komplett abschirmen würde.
Bei 10mm war das kein Problem, den Tag zentriert zu setzen.
10mm waren aber schon grenzwertig. Da muss der Tag genau auf den Leser gesetzt werden, d.h. man müsste schon fast kleine Begrenzungen aufkleben.
Deshalb hab ich mich dann für die 15mm entschieden. Da läuft das Ganze problemlos.
Zwischen Tag und Magnet soll das Trägermaterial der Tags als Isolation und Abstand nicht entfernt werden.
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)
. Also das ist jetzt nicht bös’ gemeint, aber ich kann das nicht alles testen und habe dafür auch keinen Testaufbau.
.