Homemade Spark 2 xAC

Projects
22

I have the top switch to the left, and the bottom switch to the right

image
image939×946 87.9 KB

1 Like
23

To use Adafruits library with an ESP32 you’ll need to edit the library file Adafruit_PN532.cpp, line 152:

 ​Adafruit_PN532::Adafruit_PN532​(​uint8_t​ ss) { 
 ​  spi_dev = 
 ​      ​new​ ​Adafruit_SPIDevice​(ss, ​1000000​, SPI_BITORDER_LSBFIRST, SPI_MODE0); 
 ​}

1000000 should be set lower, I would try half.

1 Like
24

I tried setting it to 500000 but still getting “Didn’t find pn53x board”

1 Like
25

I would continue to lower that number as it corresponds to the SPI communication speed. (PN532 max speed is 5MHz)

Just to double check, you commented out this line?

 //​Adafruit_PN532 ​nfc​(PN532_SCK, PN532_MISO, PN532_MOSI, PN532_SS);

And kept this line, correct?

 ​Adafruit_PN532 nfc(PN532_SS);
2 Likes
26

image
image2365×1427 184 KB

1 Like
27

Success!

image
setting that line to 62500 in Adafruit_PN532.cpp gives me this. Progress! :smiley:

Now time to modify this sketch to spit out some text if valid uid is scanned…

1 Like
28

Hi
Can anyone upload a video of the sequence with the use cases?

Tanks!

29

This project has been converted into a library that can be found here:

The catch is Vivokey’s API2 servers are currently down so the library is currently non-functional.

I would update the original posting but I can’t edit it for some reason.

30

very nice,
I did notice that you changed your github repository, so the link in your original post is no longer valid.
and the pn532 link is no longer valid aswell.

edit: nvm, you beat me with an explanation :smiley:

31

Is this what you wanted?

Screenshot_20220621-072721_Chrome
Screenshot_20220621-072721_Chrome1676×464 96.9 KB

32

@amal
I understand that you are going to do a complete overhaul of the backend that we currently use with the Spark v1/v2. Will projects such as this continue to work once you migrate us over to the new platform?

33

This is using the new API already afaict.

Also, I’m willing to bet, should that API be scrapped too: yes, this will be possible, and if not, amal will make it possible.

3 Likes
34

That is good to know. Getting ready to dive into a bunch of access systems and trying to decide on implementation based on project location.

1 Like
35

I highly recommend an adaptive approach to any system that relies on external APIs. For example, you can rely on secure chip authentication when the API is accessible and the internet is functioning properly… but if you are unable to access the API for some reason, then use of the chip UID plus a second factor like a pin code might be a good fallback option.

Of course putting a pin pad outside kind of sucks. I kind of like the idea of using a smartphone app as a dumb interface for such a thing. Basically the idea is that you install an app on your phone but it doesn’t do anything except communicate pin code digits typed on the screen to the access system over Bluetooth or something like that. I really don’t like the idea of making the phone part of the security model… they are great interface devices and should be relegated to that task.

1 Like
36

I understand what you mean as the determining factor for implementing this particular system requires internet. I do not like the idea of adding in a pin pad but it is a good option. I would ideally like to find a way to use a xHT, xSLX, xDF2 or flexDF2 as a backup. Not 100% positive but I feel like these would be the most secure chips to use since they are harder to clone if at all and the desfire chip has the challenge response feature.

I have also been looking into the external reader someone posted in a thread awhile back although I was planning to use it for a different purpose. Might be a good option for this as well. Wireless NFC Reader - µFR Nano Online - NFC Reader module with WiFi, BLE, Ethernet, UART, RS232, USB, I/O

1 Like