I am working with my Ardunio and the contactless reader/writer MFRC522 from NXP. I am using my ePassport (EU standard) and I want to start the Basic Access Control (BAC) procedure by sending the Get Challenge APDU command to its RFID chip.
Here in stackoverflow I found the APDU 00 84 00 00 08. To implement it on my Ardunio project I use the library of miguelbalboa (accessed here). Within this library there is a method to send data to an RFID chip and store its response. But first I get the ATQA which is the ATR equivalent to a contact card (which is in my case 00 08) and then a SAK (which is in my case 20). The library notes that it detected PICC compliant with ISO/IEC 14443-4 in my ePassport and finally I get its randomized UID. Next step I try to get the challenge with
// create MFRC522 instance „mfrc522“
// Init SPI bus
// Init MFRC522 device
// Select RFID chip (PICC_Select method)
byte sendData[] = {0x00, 0x84, 0x00, 0x00, 0x08};
byte backLen = 10; // I know that the answer (= the challenge) is 8 bytes long + 2 bytes for SW1 + SW2
byte sendLen = sizeof(sendData);
byte backData[backLen];
MFRC522::StatusCode status = mfrc522.PCD_TransceiveData(sendData, sizeof(sendData), backData, &backLen);
// Print „status“
No matter what I do/change/extend, the StatusCode returned is always
Timeout in communication
and I can’t find out: What am I doing wrong? I am now doubting that it is a programming error but maybe rather a hardware issue? Maybe the FIFO buffer on the MFRC522 does not accept this command although I didn’t find any restrictions in its technical specs but then I am thinking: all I do is sending and receiving bytes according to the ISO/IEC 7816-4 standard with an ISO/IEC 14443-4 contactless RFID chip…
EDIT: I tried the APDU command with my NFC device in my smartphone and an APDU Debug app from Google Play Store and there it works fine! So the chip or the APDU command itself can’t be the problem.
Have you tried sending a T=1 block?
The Block format PCB|CID|INF|EDC. This is described in http://read.pudn.com/downloads64/ebook/225463/M305_DESFireISO14443.pdf
I had success sending the GetVersion to DESFire but it timeout trying to fetch the next frame (0xAF)
Related
I have an RFID RC522 reader which reads 16-digit card number and a mini keyboard attached to Arduino Mega 2560 Rev3 which reads 4-digit Pin Number. Now I have attached a ESP-8266 Wi-Fi module in order to send that 16-digit card number and 4-digit pin to server for verification whether it is valid card user. So now I want to send both card number and pin to server at once to make less number of requests to server.
Now I want to ask that whether there’s enough memory in Arduino to store 20 digits temporarily and get a bool value from server whether it is a valid user or not.
The ATmega2560 in the Mega2560 has the following memory space :
Flash 256k bytes (of which 8k is used for the bootloader)
SRAM 8k bytes
EEPROM 4k byte
The microcontroller on the Arduino and Genuino AVR based board has EEPROM: memory whose values are kept when the board is turned off (like a tiny hard drive). This library enables you to read and write those bytes.
The supported micro-controllers on the various Arduino and Genuino boards have different amounts of EEPROM: 1024 bytes on the ATmega328P, 512 bytes on the ATmega168 and ATmega8, 4 KB (4096 bytes) on the ATmega1280 and ATmega2560. The Arduino and Genuino 101 boards have an emulated EEPROM space of 1024 bytes.
To use the specific EEPROM library use:
#include <EEPROM.h>
Examples
EEPROM Clear: Clear the bytes in the EEPROM.
EEPROM Read: Read the EEPROM and send its values to the computer.
EEPROM Write: Stores values from an analog input to the EEPROM.
EEPROM Crc: Calculates the CRC of EEPROM contents as if it was an array.
EEPROM Get: Get values from EEPROM and prints as float on serial.
EEPROM Iteration: Understand how to go through the EEPROM memory locations.
EEPROM Put: Put values in EEPROM using variable semantics.
EEPROM Update: Stores values read from A0 into EEPROM, writing the value only if different, to increase EEPROM life.
The full reference is here: https://www.arduino.cc/en/Reference/EEPROM
To summarise and answering specifically to your question, yes it is possible to store your amount of data in Arduino Mega, also using the EEPROM whose values are kept when the board is turned off (like a tiny hard drive). All the best
I need to communicate with a device using Arduino through RS232, I have everything setup and working. My problem is that the company that made the device a I need to communicate with told me the following:
1) The data sent through serial have one start and stop bit and is the hex "7E".
2) On the end of the message is appended a CRC hash
The device uses a request/response protocol, so the Arduino board must send the data in order to receive something. I've set the start and stop bit as ASCII characters put the data and CRC in between and simply Serial.write(data); I've setup two Arduino boards and both communicating this way. Everything went fine.
But with the device itself it's not working. The device sends back a response like "CE 0F " with spaces in between. So I start searching more about serial communication and found about start and stop bits and parity and start wondering if I'm sending and receiving data in the way the device expects.
To send and receive I used the basics tutorials like:
if (Serial.available() > 0) {
// read the incoming byte:
incomingByte = Serial.read();
// say what you got:
Serial.print("I received: ");
Serial.println(incomingByte, DEC);
}
So far I don't understand very well this type of communication. So I want to know why, for example some resources says that the start bit is 0 and the stop bit is 1, and in this case the start and stop bit is "7E".
I'm suspecting that this has something with:
https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
I've been trying to control Panasonic PT AE3000U through computer serial port for a last few days. Computer that I am using has serial port on its back, and I've confirmed that port functions at some level by connecting RXD and TXD with jump wire.
Technical information about projector (10Mb): http://www.projectorcentral.com/pdf/projector_manual_4506.pdf
Section that tells about serial communications starts from page 51.
According to manual and that what I've read from online, start-up command in hex should be 02 50 4f 4e 03, but I haven't been able to get it work with that.
Variations of that command I've tried to send with RealTerm and Termite:
02 50 4f 4e 03
02504f4e03
0x02 0x50 0x4f 0x4e 0x03
0x020x500x4f0x4e0x03
And other similar combinations and formats
I assume that command on third row should be the right one, because if I send that as numbers with Realterm, and connect RDX and TXD together similarly as I did before, I get this on screen (display settings are "display as ascii").
http://i.imgur.com/PjpRms7.png
But when I connect cable to the projector and repeat the process, nothing happens. Baudrate is set at 9600, which should be correct.
So, I guess it somehow solved itself. I decided to restart my computer and projector. "Just in case there would be something left from all of mine failed attempts"
And it started to work, I sent line 0x02 0x50 0x4f 0x4e 0x03 with Realterm as numbers only.
My settings were:
Baudrate 9600
Parity: None
Data bits: 8
Stop bits: 1
i am using arduino isp to program a ATtiny2313 avr microcontroller.
Here is the probelm,
when i was programming the avr chip using the default fuse values, everything worked just fine.
But then, i changed the fuse bytes as i wanted to use an external 16 MHz crystal.
When i changed the lfuse value from 0x64 to 0xff (as per the calculation of the fuse bits), the microcontroller stopped responding.
Now everytime i try to program the microcontroller using arduino uno isp, i get an error message :
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATtiny2313 is 1E 91 0A
and then the fuse bytes shown after verification, very strangely are all set to 0x00 :
avrdude: safemode: Fuses OK (H:00, E:00, L:00)
i dont understand what the hell is happening and i have spent hours trying to figure out the probelm.
should the 16Mhz crystal be connected to the microcontroller while programming ?
PLEASE HELP !
Yes. When you change the configuration bits to use the external oscillator, the internal oscillator is no longer utilised - including during programming. The chip is just stuck in reset until it is provided with an external clock signal. When the ISP attempts to read out a value it is just seeing the data line stuck in the reset state - which is where all the 0x00 values are coming from.
Hook up the crystal or a signal generator to the CLOCKIN pin and you should be able to talk to the chip again.
Had the same issue. If you do not have an external oscillator, you can use
Arduino ISP
On PIN9 you get an osciallator signal you can put on the target on PIN XTAL1.
Saved me two 328p.
I'm building a project that uses an HID OEM75 as the access point for a locking mechanism. We're doing our control through an Arduino Duemilanove (ATmega328). We're working with SPI for the security and (apparently) support. (I realize that any RFID chip has pretty weak security.)
I'm currently struggling with receiving bytes via SPI from the card reader.
The card reader is in autonomous read mode, meaning it reads a card, sends a signal to the Arduino (via a card present line, separate from SPI), which tells the Arduino to pull the Slave Select line high to activate the transfer cycle from the card reader. This is where I run into trouble, I can't understand how I can get the Arduino to simply read the bytes coming in from the card reader without sending any command bytes to the card reader?
The default command structure, SPI.transfer(0x00), sends a byte (in this case the dummy byte 0x00) and then accepts a byte from the source, but because our source is operating autonomously, it won't accept the dummy byte (and that will actually mess up its operation).
To word it simply: how can we accept a string of bytes from the slave source without sending bytes from the Master Source, using Arduino's SPI library?
If I am not wrong, using the SPI bus as a master is like shifting a dummy byte to the slave while reading the incoming byte in reverse.
USB HID Host driver for Windows from embedded24.net
Well it's a little late, but hey, it'll help someone out there.
First off:
which tells the Arduino to pull the Slave Select line high to activate
the transfer cycle from the card reader.
This is SPI, you pull the Slave Select low to activate the slave, not high. You put it high to tell it to shut up while others are talking.
I can't understand how I can get the Arduino to simply read the bytes
coming in from the card reader without sending any command bytes to
the card reader?
That's because you don't. In SPI, the master (which the arduino is set up as and the SPI.h library assumes) initiates communication. It sends out data on the MOSI line and the slave responds on the MISO line. If you have nothing to say to the slave, just send 0xFF or whatever dummy bytes and then check what came in on the MISO. On the arduino, I believe that gets stored in the SPDR, SPI data register. Or use whatever the spi library gives you.
but because our source is operating autonomously, it won't accept the
dummy byte (and that will actually mess up its operation).
If the case is that you really can't send data to the SPI slave device without it screwing up, then it's not actually implementing SPI, and the arduino SPI library won't help you. You'll have to hack out your own solution. The SPI standard is actually pretty loose and all sorts of people do it their own special way. Which is vastly annoying. I've seen devices use the SS line to initiate clock synching. Which means you can't just tie it to ground to have that slave always be on.
Before you write it off though, I'd suggest investigating why it won't accept the dummy byte. You might be using "3-wire" SPI which combine MOSI and MISO and turn it from full duplex into half duplex, and you'll have to get the timing right so you don't trample everything.
When getting into the nitty gritty of SPI, an oscilloscope works wonders for seeing what actually happened vs what you think should have happened.