ESP32 wiegand interrupts in IRAM?

[jpadie]

Does anyone successfully AND reliably have this lib working with ESP32? I notice that neither of the ISRs are in IRAM (which will normally cause kernel panics or stack smash issues) and there are no calls to suspend interrupts nor debounce them (other than the timer condition in DoWiegandConversion()).

In my test setup I am getting no wiegand data received by the sketch at all!

[jpliew]

Many reported that this lib working with ESP32.

[jpadie]

Thank you. I can't see how that can be accurate when the interrupt handlers are not in IRAM. I suspect that they are getting odd errors that they have been unable to attribute.

Is there a specific reason you don't use iram for your interrupt handlers? And why you don't stop interrupts whilst the interrupt handlers are accessed?

[jpadie]

I have it working relatively robustly using iram. Frequently, unfortunately, button presses are not recognised however. I can see the interrupt handler being triggered but no code being reported.

[jpliew]

Thank you. I can't see how that can be accurate when the interrupt handlers are not in IRAM. I suspect that they are getting odd errors that they have been unable to attribute.

I have tested with the original ESP32 Wrover kit and was able to get 100 out of 100 scans correct. If it was not working, there should be more issues lodged here. Moreover it is not mandatory to have interrupt vector in IRAM when there was no FLASH operation involved.

Please see official ESP32 documentation https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/intr_alloc.html

This is useful for interrupts which need a guaranteed minimum execution latency, as flash write and erase operations can be slow (erases can take tens or hundreds of milliseconds to complete).

Is there a specific reason you don't use iram for your interrupt handlers?

No specific reason. This library was written before there was ESP32, it was written for pure Arduino. Since the appearance of ESP32, more and more people reported that this library is working with ESP32. So I can't find any reason why we need to change it when it is working.

And why you don't stop interrupts whilst the interrupt handlers are accessed?

There are two types of interrupts handling method,

1. non-reentrant - used to process critical interrupt when no other interrupts should happen.

and

2. reentrant - used when other interrupts can happen, or the same interrupt can be processed over and over again, or when the the interrupt is also depending on other interrupt (example timer interrupt).

This library is also depending on the timer interrupt to take care of the timing, so it uses the reentrant method.

Hope this explains all your queries.

[Netoperz]

@jpliew

What if I use buffer ? for storing the code, it makes problems with interupts i have also noticed that.

This is my task for wiegand operations, here it is cutted out from main code and i have problems. Not every input gets to me. COuld You test it ?

This was tested on atmega 32u4 (i started to think about using it as coprocessor for esp32 for handling wiegand) but there are the same problems.

I get some inputs than some not, and than again fine, The code is below, I'm sorry for the code, i'm not a proffesional developer, , and really may say not a dev at all :D just started learning a year or two ago so there might be some errors. Could someone throw me a bone what the hack i'm doing wrong ?

The code should do:

1. read wiegand and store input in buffer , i'm using 5 digit pin codes in my project
2. if the reader sends the long value it means that it is card, so it should be processed right away not waiting for whole 5 inputs. just send it to serial
3. if there are 5 inputs just send them to serial
4. if someone have pressed some keys but not full 5 digit code, after some time just clear the buffer to be ready for next use.
5. clear the buffer when # is pressed.
6. i do not use internal input confirmation, i want to blink a led or use sound buzzer to confirm that input was recieved by the MCU.

that's all. And here is working code, but as i'm not an expert i think that interupts are fu%^*d , and not every input is recieved. The cabling is 15 cm cable from keypad to the atmega (or esp32) , powered by the 3A 5v powersource and active USB HUB, so no problems with power (esp32 does not like weak power like USB)

If someone can help improve that code i would be in heaven.

So here is the code:

``/====================================================================== Atmega32u4, Arduino/Genuino Pro Micro Leonardo /======================================================================/

include

define PIN_BUZZER 6

define PIN_LED 5

define BR_0 115200

define BR_1 9600

unsigned int WiegandInputCouter = 0; unsigned int WiegandInputCouterLimit = 300;

WIEGAND wg;

long codeBuffer[5]; unsigned int countCode = 0;

//====================================================================== // PIN TO STRING //====================================================================== void processingPinCode() { char pinCodeInput[5]; sprintf(pinCodeInput, "%lu%lu%lu%lu%lu", codeBuffer[0], codeBuffer[1], codeBuffer[2], codeBuffer[3], codeBuffer[4]); String pinCode((char *)pinCodeInput); Serial.print("PIN CODE : "); Serial.println(pinCode); Serial1.print(pinCode); clearBuffer(); }

//====================================================================== // CARD TO STRING //====================================================================== void processingCardCode(unsigned long codeToCheck) { char accessRequestCode[24]; sprintf(accessRequestCode, "%lu", codeToCheck); String cardCode((char *)accessRequestCode); Serial.print("CARD NUMBER: "); Serial.print(accessRequestCode); Serial1.print(accessRequestCode); clearBuffer(); }

//====================================================================== // MANUAL MEM. CLEAR //====================================================================== void clearBufferIfHash() { for (int i = 0; i < 5; i++) { if (codeBuffer[i] == 13) { WiegandInputCouter = 0; countCode = 0; memset(codeBuffer, -1, sizeof(codeBuffer)); Serial.println("CLEAR MEM BY #"); } } } //====================================================================== // CLEARING MEM //====================================================================== void clearBuffer() { WiegandInputCouter = 0; countCode = 0; memset(codeBuffer, -1, sizeof(codeBuffer)); }

//====================================================================== // LED KEYPRESS CONFIRM //====================================================================== void runInputConfirmLed() { //digitalWrite(PIN_BUZZER, LOW); // delay(15); digitalWrite(PIN_LED, LOW); delay(80); //digitalWrite(PIN_BUZZER, HIGH); // delay(15); digitalWrite(PIN_LED, HIGH); delay(10); }

//====================================================================== // IS IT CARD CODE FROM KEYPAD OR NOT //====================================================================== bool isCardCode(unsigned long currentCode) { if (currentCode > 99) { return true; } return false; }

//====================================================================== //############################ SETUP ################################## //====================================================================== void setup() { Serial.begin(BR_0); Serial1.begin(BR_1); wg.begin(2, 3);

pinMode(PIN_BUZZER, OUTPUT); pinMode(PIN_LED, OUTPUT); digitalWrite(PIN_BUZZER, HIGH); digitalWrite(PIN_LED, HIGH);

memset(codeBuffer, -1, sizeof(codeBuffer)); }

//====================================================================== //############################ MAIN LOOP ############################## //====================================================================== void loop() {

if (wg.available()) { runInputConfirmLed(); //confirming input WiegandInputCouter = 0; //resetting the timer for autoclearing the buffer unsigned long currentCodeProcessing = wg.getCode(); if (isCardCode(currentCodeProcessing)) //checking if it is card number sent from keypad { processingCardCode(currentCodeProcessing); // coverting to string and printing the code and sending to second serial clearBuffer(); } else // clearing buffer if "#" is pressed, or printing the 5 digit buffer if there are 5 digits in buffer (i want to use 5 digit pincodes) { countCode++; if (countCode < 6) { codeBuffer[countCode - 1] = wg.getCode(); for (int i = 0; i < 5; i++) { clearBufferIfHash(); Serial.println(codeBuffer[i]); } if (codeBuffer[4] > -1) { processingPinCode(); // coverting to string and printing the code and sending to second serial delay(10); } } } } else // auto clearing the buffer if no input for some time { if (codeBuffer[0] > -1) { WiegandInputCouter++; if (WiegandInputCouter == WiegandInputCouterLimit) //clearing the buffer if there were left some inputs in buffer but no card and no full 5 digit code was given. { WiegandInputCouter = 0; countCode = 0; clearBuffer(); Serial.println("AUTO CLEAR MEM."); } } } delay(50); }

//====== END

[jpliew]

@Netoperz I have not go through all you code, but a quick check, the delay() in the main loop and LED is the main suspect.

The generic frame to frame separation for wiegand is 25ms , your delays are many time over that. Meaning while flashing the LED or waiting in the main loop, you are loosing the other wiegand data that are coming in.

Also you should make use of getBitCounted() to identify if the data is a keypress or card scan.

[Netoperz]

@jpliew When i was thinking about how to verify if the input is complete i thought that there is no freaking way to input negative value using keypad, so i'm using -1 as impossible input reference in buffer. The delays were used as kind of timers for automatic buffer "clearing" if smeone would left some inputs for example 3 digits, not 5 as full pincode for access verification. to be sure that next user will get the free clean buffer. but it can be done with starting input with # so i'll comment out the delays, and the part of the code for that "timer counter" and i'll check again.

[Netoperz]

I've checked, with the code below, there is a bit better , but still first keypres is gone than 2-3 ok, next 2-5 gone. quite random. sometimes if i press keys slower it is better. I have removed all delays, all unnecesary operations, the timer counter for clearing, whole led operations as you have sugested. The only thing i could remove more are Serial debug from serial0 but i think that this is not a surce of the problem. An whole tests were made on Atmega 32u4 Arduino Pro micro clone, ihave a few of them, keypad connected directly to the arduino board (both are 5v tll so no level converters or so. I'm using keypad from local importer, with vidiline name on it but it is popular model from china sold with many names /stickers I think it is made by SecuKey https://fr.aliexpress.com/item/SK2-R-Free-Shipping-Keypad-Wiegand-Reader-Waterproof-Conforms-To-IP66-Wiegand-26-37-Bits-Output/32817116561.html

https://www.genway.pl/product/attachment/08564f3fe4e658a1d8ac86dabd2cc900/pl_PL/vidi-ac-2cs-ang.pdf

This keypad is not made of gold but is fine, and works well. i have got a few of them. also tested with other brands, the same behavior. And when those keypads are connected to other hardware with wiegand interface there are no problems, 100% inputs fine, so i'm sure that this is related to my code or the lib. You may test my code if you find a free time. As esp32 may not work as expected when this code is a task with over 2600 lines of other code. It should work fine as standalone code on atmega 32u4 i think, but it has some glitches.

The code is below:

`//====================================================================== // Atmega32u4, Arduino/Genuino Pro Micro Leonardo works on esp32 //======================================================================

include

define PIN_BUZZER 6

define PIN_LED 5

define BR_0 115200

define BR_1 9600

WIEGAND wg;

long codeBuffer[5]; unsigned int countCode = 0;

//====================================================================== // PIN TO STRING //====================================================================== void processingPinCode() { char pinCodeInput[5]; sprintf(pinCodeInput, "%lu%lu%lu%lu%lu", codeBuffer[0], codeBuffer[1], codeBuffer[2], codeBuffer[3], codeBuffer[4]); String pinCode((char *)pinCodeInput); Serial.print("PIN CODE : "); Serial.println(pinCode); Serial1.print(pinCode); }

//====================================================================== // CARD TO STRING //====================================================================== void processingCardCode(unsigned long codeToCheck) { char accessRequestCode[24]; sprintf(accessRequestCode, "%lu", codeToCheck); String cardCode((char *)accessRequestCode); Serial.print("CARD NUMBER: "); Serial.print(accessRequestCode); Serial1.print(accessRequestCode); }

//====================================================================== // MANUAL MEM. CLEAR //====================================================================== void clearBufferIfHash() { for (int i = 0; i < 5; i++) { if (codeBuffer[i] == 13) { countCode = 0; memset(codeBuffer, -1, sizeof(codeBuffer)); Serial.println("CLEAR MEM BY #"); } } } //====================================================================== // CLEARING MEM //====================================================================== void clearBuffer() { countCode = 0; memset(codeBuffer, -1, sizeof(codeBuffer)); }

//====================================================================== // IS IT CARD CODE FROM KEYPAD OR NOT //====================================================================== bool isCardCode(unsigned long currentCode) { if (currentCode > 99) { return true; } return false; }

//====================================================================== //############################ SETUP ################################## //====================================================================== void setup() { Serial.begin(BR_0); Serial1.begin(BR_1); wg.begin(2, 3);

pinMode(PIN_BUZZER, OUTPUT); pinMode(PIN_LED, OUTPUT); digitalWrite(PIN_BUZZER, HIGH); digitalWrite(PIN_LED, HIGH);

memset(codeBuffer, -1, sizeof(codeBuffer)); }

//====================================================================== //############################ MAIN LOOP ############################## //====================================================================== void loop() {

if (wg.available()) { unsigned long currentCodeProcessing = wg.getCode(); if (isCardCode(currentCodeProcessing)) //checking if it is card number sent from keypad { processingCardCode(currentCodeProcessing); // converting to string and printing the code and sending to second serial clearBuffer(); } else // clearing buffer if "#" is pressed, or printing the 5 digit buffer if there are 5 digits in buffer (i want to use 5 digit pincodes) { countCode++; if (countCode < 6) { codeBuffer[countCode - 1] = wg.getCode(); for (int i = 0; i < 5; i++) { clearBufferIfHash(); Serial.println(codeBuffer[i]); } if (codeBuffer[4] > -1) { processingPinCode(); // coverting to string and printing the code and sending to second serial clearBuffer(); } } } } }

//====== END`

[Netoperz]

@jpliew this is output from the same keypad on the same board with the Wiegand test example.

those are 5 times in a row 1,2,3,4,5,6,7,8,9,0, key presses. as You see there is lack of some inputs. Every key press per second (about):

Wiegand HEX = 2, DECIMAL = 2, Type W4 Wiegand HEX = 3, DECIMAL = 3, Type W4 Wiegand HEX = 4, DECIMAL = 4, Type W4 Wiegand HEX = 5, DECIMAL = 5, Type W4 Wiegand HEX = 6, DECIMAL = 6, Type W4 Wiegand HEX = 1, DECIMAL = 1, Type W4 Wiegand HEX = 3, DECIMAL = 3, Type W4 Wiegand HEX = 5, DECIMAL = 5, Type W4 Wiegand HEX = 0, DECIMAL = 0, Type W4 Wiegand HEX = 1, DECIMAL = 1, Type W4 Wiegand HEX = 3, DECIMAL = 3, Type W4 Wiegand HEX = 4, DECIMAL = 4, Type W4 Wiegand HEX = 6, DECIMAL = 6, Type W4 Wiegand HEX = 7, DECIMAL = 7, Type W4 Wiegand HEX = 8, DECIMAL = 8, Type W4 Wiegand HEX = 9, DECIMAL = 9, Type W4 Wiegand HEX = 0, DECIMAL = 0, Type W4 Wiegand HEX = 1, DECIMAL = 1, Type W4 Wiegand HEX = 3, DECIMAL = 3, Type W4 Wiegand HEX = 4, DECIMAL = 4, Type W4 Wiegand HEX = 5, DECIMAL = 5, Type W4 Wiegand HEX = 6, DECIMAL = 6, Type W4 Wiegand HEX = 7, DECIMAL = 7, Type W4 Wiegand HEX = 8, DECIMAL = 8, Type W4 Wiegand HEX = 1, DECIMAL = 1, Type W4 Wiegand HEX = 2, DECIMAL = 2, Type W4 Wiegand HEX = 3, DECIMAL = 3, Type W4 Wiegand HEX = 5, DECIMAL = 5, Type W4 Wiegand HEX = 6, DECIMAL = 6, Type W4 Wiegand HEX = 8, DECIMAL = 8, Type W4 Wiegand HEX = 0, DECIMAL = 0, Type W4

[jpliew]

@Netoperz please use WiegandNG test example. This library will isolate invalid data. I believe you have hardware issue. WiegandNG will print out anything. The missing data are either shorter than 4 bit or longer than 4 bit.

I never have a miss using this library with keypad. No matter how fast or how slow I enter.

[Netoperz]

@jpliew I have tested the multibit example. 100% read, very fast key pressing, so below the same test on the same hardware but with multibit lib. 5 times keys from 1 to 0. 100% captured by arduino.

5, 74407, 74391,74391 Bits=5 RAW Binary=00001 6, 74752, 74735,74735 Bits=6 RAW Binary=000010 4, 75100, 75084,75084 Bits=4 RAW Binary=0011 5, 75425, 75409,75409 Bits=5 RAW Binary=00100 4, 75744, 75728,75728 Bits=4 RAW Binary=0101 4, 76065, 76049,76049 Bits=4 RAW Binary=0110 4, 76383, 76367,76367 Bits=4 RAW Binary=0111 5, 76707, 76691,76691 Bits=5 RAW Binary=10000 4, 77066, 77050,77050 Bits=4 RAW Binary=1001 4, 77406, 77390,77390 Bits=4 RAW Binary=0000 5, 78934, 78917,78917 Bits=5 RAW Binary=00011 5, 79323, 79307,79307 Bits=5 RAW Binary=00010 4, 79723, 79707,79707 Bits=4 RAW Binary=0011 4, 80072, 80056,80056 Bits=4 RAW Binary=0100 4, 80421, 80405,80405 Bits=4 RAW Binary=0101 4, 80760, 80744,80744 Bits=4 RAW Binary=0110 4, 81110, 81094,81094 Bits=4 RAW Binary=0111 5, 81489, 81473,81473 Bits=5 RAW Binary=10000 4, 81848, 81832,81832 Bits=4 RAW Binary=1001 4, 82188, 82172,82172 Bits=4 RAW Binary=0000 4, 85292, 85276,85276 Bits=4 RAW Binary=0001 4, 85731, 85715,85715 Bits=4 RAW Binary=0010 5, 86191, 86175,86175 Bits=5 RAW Binary=00011 5, 86616, 86600,86600 Bits=5 RAW Binary=01000 5, 87009, 86993,86993 Bits=5 RAW Binary=01001 4, 87400, 87384,87384 Bits=4 RAW Binary=0110 4, 87749, 87733,87733 Bits=4 RAW Binary=0111 4, 88128, 88112,88112 Bits=4 RAW Binary=1000 4, 88497, 88481,88481 Bits=4 RAW Binary=1001 5, 88857, 88841,88841 Bits=5 RAW Binary=00000 4, 90863, 90847,90847 Bits=4 RAW Binary=0001 5, 91312, 91296,91296 Bits=5 RAW Binary=00010 4, 91722, 91706,91706 Bits=4 RAW Binary=0011 5, 92121, 92105,92105 Bits=5 RAW Binary=01000 5, 92521, 92505,92505 Bits=5 RAW Binary=01001 4, 92899, 92883,92883 Bits=4 RAW Binary=0110 4, 93279, 93263,93263 Bits=4 RAW Binary=0111 4, 93648, 93632,93632 Bits=4 RAW Binary=1000 4, 94078, 94062,94062 Bits=4 RAW Binary=1001 5, 94438, 94422,94422 Bits=5 RAW Binary=00000 4, 95625, 95609,95609 Bits=4 RAW Binary=0001 5, 96014, 95998,95998 Bits=5 RAW Binary=00010 4, 96384, 96368,96368 Bits=4 RAW Binary=0011 4, 96744, 96728,96728 Bits=4 RAW Binary=0100 4, 97143, 97127,97127 Bits=4 RAW Binary=0101 5, 97542, 97526,97526 Bits=5 RAW Binary=00110 4, 97951, 97935,97935 Bits=4 RAW Binary=0111 4, 98376, 98360,98360 Bits=4 RAW Binary=1000 5, 98779, 98763,98763 Bits=5 RAW Binary=10001 5, 99169, 99153,99153 Bits=5 RAW Binary=00000

[Netoperz]

@jpliew and here 10 times the same key "1" on keypad fast. I see that it is 4 bits sometimes 5 sometimes 6. So my "lost" input are those 5 and 6 bits transmissions. You were right. Thank You.

Still cannot explain why this keypad has got 100% good input when connected as external keypad to other "wiegand systems/devices" it looks like they can fix/ignore wrong data ?

But why is that happening ? I'm sure that there are no interferences and cabling is soldered well. What do You suggest ?

Page 13 of the user manual: https://www.genway.pl/product/attachment/08564f3fe4e658a1d8ac86dabd2cc900/pl_PL/vidi-ac-2cs-ang.pdf

4, 376796, 376780,376780 Bits=4 RAW Binary=0001 6, 377165, 377149,377149 Bits=6 RAW Binary=000001 4, 377554, 377538,377538 Bits=4 RAW Binary=0001 5, 377953, 377937,377937 Bits=5 RAW Binary=00001 4, 378344, 378328,378328 Bits=4 RAW Binary=0001 4, 378703, 378687,378687 Bits=4 RAW Binary=0001 4, 379082, 379066,379066 Bits=4 RAW Binary=0001 4, 379471, 379455,379455 Bits=4 RAW Binary=0001 4, 379851, 379835,379835 Bits=4 RAW Binary=0001 5, 380240, 380224,380224 Bits=5 RAW Binary=00001

[jpliew]

Your D0 captured extra noise. D1 is good. I am sure is noise or interference in your Arduino or wiring.

[Netoperz]

@jpliew I have changed the coding to 8 bits, but still D0 gets extra bits, so i have contacted the company selling them , they will check it.

And now i Have other keypad, ROGER https://www.roger.pl/pl/kontrola-dostepu/system-kontroli-dostepu-racs-4/czytniki-zblizeniowe-prt/czytniki-zblizeniowe-13-56-mhz-mifare/prt64mf-czytnik-zblizeniowy-mifare.html

I have tested this one on the same hardware, and it is much much better. But in 30 reads in a row still some extra bits. rare but from time to time they appear.

I have got five more same keypads and i'll check them too, and one from other manufacturer.

Here You got terminal output from the roger keypad.

30 times in a row key "1"

Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=9 RAW Binary=111000001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=9 RAW Binary=111000001 Bits=9 RAW Binary=111000001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001 Bits=8 RAW Binary=11100001

[Netoperz]

@jpliew I have got a question. What should be going on when the wiegand input pins were left not connected on arduino ? Exacly when the arduino runs, what the code should do if there is no keypad attached to pin 2 3 and gnd ? I assume it should be silent

But when I disconnect the keypad i getsome 0, that might be those extra bits... but why ? Is it possibe to pull up/down the lines if they are floating ? or something ?

If i left the arduino without keypad connected from time to time i see: 0 0 0 0 0 PIN CODE : 00000 0 -1 -1 -1 -1 0 0 -1 -1 -1 0 0 0 -1 -1

So it gets zeros, its from static charges i think, because i'm sitting on my sofa. Is there a way to better filter out those things ? for example if my keypads LED is trigered low, i pull up the pin to avoid accidental trigger, could something like that be done on arduino regarding the wiegand interface ?

[jpliew]

@Netoperz when you execute wg.begin() the code already attached the pins to get ready for interrupt input. It will be always ready. Even though there is no output from the wiegand reader, when you disconnect the wires, the movement of the wires causing sparks (the current is too low, you can see the fire but it is there), sparks cause noise that triggers the input pin of the Arduino. This is a normal behavior of electronics nothing to do with the library.

There is also a possibility that your wires are not connected securely causing the vibration that introduce the noise. But without seeing I can't confirm.

My suggestion before still valid, you need an oscilloscope to confirm. Connect the scope to D0 and D1, watch when and where the noise show up. Shake the reader and watch the scope, scan and watch the scope, do whatever and see what is causing the scope.

If you are doing a commercial project, a Rigol oscilloscope is only about $300+ and should be a justifiable investment. If not, find someone and borrow.

[jpliew]

Please start a new issue if you have question related to the library. This issue is about ESP32 running in IRAM.

[Netoperz]

@jpliew Thank You, this is not commercial yet, it intends to become, but problems with input devces holds things in place. I will buy rigol for sure, for now i had some more important things, you know family :D This is not my issue, so we have explained everything, my opinion is that your library and code till now is awesome work, and I have learned a lot thanx to You, Hope i could do something for you in exchange.

There is also a possibility that your wires are not connected securely causing the vibration that introduce the noise. But without seeing I can't confirm.

This is my case, i never thought that this interface is so prone to inductive interference, How others are handling that problem ? I've seen a lot of installations with so poor cabling, and the devices work fine, when i'm using arduino/esp it's so fragile.

@jpadie I'm using this library for some time, on ESP32 this library works fine for esp32. As You may already know, the wiegand interface is not perfectly safe in term of interference resistance. You must remember that for connecting ESP32 to wiegand hardware You need to use level shifters (3.3v to 5V) and if You do so, i'm sure that no input/output at all is caused by those level shifters. Or You have burned the GPIO already, another thing is that there are input only gpios, and they are problematic, Also bootsrapping pins should be avoided.

Here You have some good info about ESP32 and how to choose the pinout and why, it helped me, so it might help You. Remember that ESP32 works differently than arduino, The arduino code is a abstraction layer over native IDF. For example when You use delay() it does not stop the code, it just call vTaskdelay() that holds that particular task and the rest of task can run.....

https://randomnerdtutorials.com/esp32-pinout-reference-gpios/

I had 5 or 6 of them , and only one type works fine. If you need any help assistance please send me msg. I'll help you to solve the problems, as Jpliew is helping me and others.

So for now "Huston over and OUT"

[ipqate]

Hi, maybe it is late (maybe not....)

For those having problems losing button presses, try this: put some pull up resistors between the power and Data 0 and power and Data 1.

It does not solve the problem 100% but improves the overall stability.

Regards