I'm configuring a terminal for use with contactless VISA cards. I understand that terminals can be setup to support legacy MSD mode, EMV/qVSDC mode or both.
I have an EMV testing tool, so I am able to see all the communication between the testing card and the terminal. Generally, I've found AIP Byte 2 bit 8 gives an indication if the card supports EMV contactless mode, but this doesn't seem to be the case for VISA cards.
Assuming a terminal is configured for both, how would someone recognise if a transaction occurred using MSD mode or qVSDC mode?
MSD mode is implemented for infrastructures which are not yet upgraded to process full grade emv transactions, but at the same time wants to use the capability of the chip to increase the security. In case of MSD transaction, the there will not be DE55 elements, but a dynamic cvv(CVN 17) in track. Otherwise, it will look like a magnetic stripe transaction.
Where as qvsdc is a full grade EMV transactions, it has cryptogram and other DE55 elemsts.
In fact I heard Visa is looking to establish a sunset date for the contactless MSD processing.
Per the visa contactless implementation guide dcvv is sent with msd and NO chip data. CVN17 is for when msd data AND chip data. and CVN18 is for full emv contactless.
Related
I have a Gateway - Node application using the LoRa module but I don't know whether to choose the LoRa module to interface UART or SPI.
Can someone help me distinguish the difference when using these two types? Example: when I have 5 Nodes connected to Gatewway, which one should I use? and same when I have 50 Nodes.
Thanks!
A UART converts the signals to RS232 signaling(NOT VOLTAGES, You will need an additional adapter chip like the FTDI 232H) to hook up to a serial port on a computer. Speeds are usually limited to less than 400 Kilobits per second(varies based on distance and devices)
If you are connecting multiple devices to the same micro-controller(Arduino), use SPI. The connection speeds are not limited by standards. It is a bus arrangement with 4 pins (clock SCLK, input MISO, output MOSI and Slave select SS) The SCLK, MISO, MOSI are connected to all devices.To chain additional devices it requires an additional SS pin per device.
SPI is going to be faster(several (<5?)Megabits per second is not uncommon (depends on length(not greater than .3 meters), wire quality, environmental noise and device specifications) and requires less discrete components.
Since LoRa speeds max out around 300kbps, a single SPI connected gateway could theoretically handle 15 LoRa transceivers on a single gateway.
Doing 15 devices may violate local RF duty cycle restrictions resulting in fines and/or imprisonment.
Please check with your regulatory institutions prior to implementation of any solution.
I would suggest using four transceivers with external antennas each pointing in a different cardinal direction(possibly offset) at each gateway. This configuration should permit 400+(depending on usage patterns) client devices per gateway.
I'm learning embedded development, and I'm trying to communicate with the accelerometer (LIS3DSH) on the discovery board using the SPI protocol. I'm only using CMSIS headers so that I'm forced to interact directly with the registers.
According to the schematics, these are the pins being used by the board for communication with the accelerometer:
PA5: SPI1_SCK
PA7: SPI1_MOSI
PA6: SPI1_MISO
PE3: CS_I2C/SPI
From my theoretical understanding of the SPI protocol, whenever I want to receive or transmit data between the master and the slave, I first need to pull the CS pin (PE3) down and then start the communication. This seems to be confirmed by the LIS3DSH user manual as well.
But now I'm confused about what the meaning of SSM is. According to the board's user manual, this is what the software slave management bit does:
When the SSM bit is set, the NSS pin input is replaced with the value from the SSI bit.
The NSS pin is nothing but the slave select pin, right? Which means it is PE3 in this case.
The SSI bit is bit 8 on the SPI_CR1 register. Does this mean I should instead toggle this SSI bit instead of PE3? That doesn't make sense because how would board know that the PE3 is the relevant CS pin?
So how are the CS pin/line and the SSM bit related, if at all?
If they're not related, do I need to configure the PE3 pin with alternate function mode and and as a pull-up, and then pull it low every time I need to communicate using SPI with the accelerometer?
The NSS pin is an input used as a CS by some other device when the SPI peripheral is in slave mode, or can be used as an output to support multi-master configurations.
If you are operating the SPI in single-master mode, the pin is not used at all.
Moreover SPI1_NSS is an alternate function of PA4 or PA15 so not related to the CS GPIO on PE3 in your case. In master mode, any number of available GPIO pins may be used as CS lines for each peripheral on the same SPI bus, and is driven in software - it is not an "alternate function", and not part of, or controlled by, the SPI peripheral.
I'm currently discovering the smart card world and there are some things that I don't understand.
I'm developing a driver that talks to my smart card reader (USB) using the CCID protocol (I succeeded in having basic communications).
But then if I want to talk to my card using ISO/IEC 7816-4 specification, I will keep using the CCID protocol and in the PC_to_RDR_XfrBlock() request, in the data part (abData at offset 10 cf $6.1.4 page 30 specification of CCID) I will directly send my ISO/IEC 7816 command as READ_BINARY, WRITE_BINARY, SELECT ... And the smartcard reader will answer me using RDR_to_PC_DataBlock() ($6.2.1 page 49).
This question is OS independent, and not using any existing drivers or OS library.
Am I right?
I found my answer by analysing trames with wireshark. It seems to work as I described it.
Here are somes links that will help user that tries to do the same.
To setup usb capture :
https://wiki.wireshark.org/CaptureSetup/USB
To enable iso 7816 frames analysis in wireshark (inside ccid packets): https://ask.wireshark.org/questions/32594/iso-7816-example-capture
I have a Netduino Plus with at transeiver attached via SPI. I would like to reset the transiever every time the Netduino restarts. Is it possible to programmatically power on/off the 3V3 pin?
I would recommend using a FET (controlled by one of the I/O) pins to enable/disable 3V3 power to your transceiver. When you say transceiver, I think "more than a few mA" :)
BTW, we took this feedback into account with the new Shield Base module for Netduino Go. It has an integrated FET on both 3V3 and 5V power headers, so you could enable/disable power to your shield in code. Once the new Ethernet go!bus module ships and the Shield Base comes out of beta (soon), your solution can be redeployed to Netduino Go + Shield Base with few/no code changes.
Chris
Secret Labs LLC
Looking at the circuit diagram ( http://www.netduino.com/netduinoplus/schematic.pdf ), I can see only the Micro SD Card Slot having its power controlled programmatically. You could rig up a relay to control it (via a transistor, of course) instead, or if the transceiver uses less than 130mA (the current limit of the device shown: http://www.datasheetarchive.com/BSS84W-7-F-datasheet.html) you could copy the circuit from the Netduino Plus. Buying a relay shield looks like overkill, but you might have other uses for it.
Have you looked into resetting the transceiver programmatically instead of the brute-force method of power-cycling it?
Just to provide another view. You could use a transistor powered off the netduino RESET line, this will reset the device every time the netduino reboots. Or you can just link the transistor to a spare digital pin and power it in code..
What specific SPI device are you using? You mention that it's a transceiver but we could probably provide better information if we know the exact part number. If your device requires less than 8mA the Netduino Plus specs seem to indicate that one option could be using a digital output pin as the power source.
Unfortunately Secret Labs don't use exactly the language I'd expect and call out the sink and source current maximums so I would contact them directly first to see if you risk blowing your chip. I'll see if I can get an answer from them and amend this post if/when I do.
Update: Sink and source current is the same on the Netduino. See my post on their forums about sink vs. source current for a more in depth explanation. So, if your device can run off of just a few milliamps you should be able to use a digital I/O pin to power it.
Also, a lot of devices have enable pins. You can usually reset them with that line instead of pulling the power if that helps. Sometimes with flaky hardware it is better to pull the power though.
We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
+--------------+ +--------------+ +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+ +--------------+ +--------+
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.