Does Mifare RFID Reader(13.56 MHz) support NFC?I want to develop an application using Nokia mobile. Is it possible to formatting the Mifare RFID cards using NFC enabled mobile?
Are you talking about the USB RFID reader? It depends, there are RFID readers with and without the NFC support... Which Nokia phones do you plan to use to communicate with RFID reader and in which mode? If this is a Symbian C7 or other model I suggest to use the C++ API for native Symbian and/or Qt.
It's very likely that your Mifare RFID 13.56 reader supports NFC. 13.56 is the high frequency range of RFID that NFC covers. There are several models of NFC readers that are guaranteed to work; there are different forms factors as well as interfaces (LCD, portable; serial, USB, ...) to choose from. You will also need software for your reader. Your Nokia phone may be able to read/write the NFC tags... it all depends on which model you have.
Related
I am starting with RFID and NFC, I have an ET50 Zebra Tablet with windows 10 and I am trying to read and write in a MIFARE Ultralight NFC card, I am using a code that I downloaded from:
https://github.com/andijakl/ndef-nfc
But till now no luck, after researching a lot I found that Windows only can read from NFC NDEF cards, so I confirmed that this MIFARE ultralight card fits that requirement and it is correct. I was also checking windows documentation and it seems that the device is only reachable by using Proximity Device Class. I did try to implement that but again no luck detecting the card.
Any help will be appreciated.
What I want to ask is - Will a BLE device be able to answer calls, play music, etc... or that Bluetooth 4.0 is intended for a kind of NFC alternative?
Bluetooth Low Energy is part of the Bluetooth 4.0 specification. Bluetooth 4.0 includes Classic Bluetooth, Bluetooth Low Energy and Bluetooth High Speed.
Bluetooth Low Energy (BLE) uses a different radio protocol with fewer, wider channels and a lower transmission rate and power than Bluetooth Classic (although it uses the same frequencies) and most importantly it implements a different set of profiles.
Classic Bluetooth has profiles such as Serial Port Profile (SPP) and Handsfree Profile (HFP) while the most commonly used profile in BLE is the Generic Attribute profile (GATT). This profile allows for the transfer of small amounts of data at relatively low speeds and is not suitable high-bandwidth time-critical applications such as audio streaming.
Dual-mode Bluetooth chipsets that support Classic Bluetooth and BLE are available although often they can only operate in one mode at a time. Many BLE chipsets are BLE only, however as it reduces cost and complexity.
The short answer is that BLE can't support the classic Bluetooth functions you described.
Bluetooth 4.0 has all backwards compatibility with it's older versions.
BLE is a form of connect using low energy technology.
BLE = Bluetooth Low energy.
They are different technologies with different proposes. BLE tend to be used in heart rate monitors, bike computers, medicinal applications and etc. Whenever the power supply is limited.
BLE intent is not for headsets and similar devices. That's why you see on phone specifications Bluetooh 4.0 + BLE (or LE). Bluetooh is a technology, BLE is a 'protocol of communication'
I'm trying to understand the layers of software that interface with USB webcams.
As I understand it:
A standard webcam fits into the category of a 'USB Video Device Class', or 'UVC'.
And in linux, Video4Linux (V4L, V4L2) encapsulates all video capture devices. V4L(2) provides two APIs: one is for programs that want to get and use the data from the capture devices. The other API is internal, for the drivers themselves, so those drivers can then be accessed by programs via V4L(2)'s external API.
One of those V4L(2) drivers is the UVC driver which encompasses all standards-compliant USB webcams.
My question:
Looking at that homepage of the UVC driver, it shows a list of supported devices. Has each one of those devices been catered for individually within the UVC driver? Or only if a device had a peculiarity that needed to be dealt with? In other words, should all standards-compliant USB webcams automatically work with the UVC driver, whether or not they're on that list?
Thanks
I believe the text right under the "Supported devices" headline answers your question:
The table below lists known UVC devices. Other UVC compliant video input devices are very likely to be supported.
So, un-listed devices that comply with the standard should work. Speaking from experience with mass storage ("USB flash drives") in embedded environments, your mileage will probably vary since not all devices are fine examples of engineering.
The USB Video Class have released manuals that have specifications, that a Vendor should implement. When a Vendor designs their product considering these specifications, that device becomes UVC Compliant.
I am using a Webcam that is UVC Compliant but not listed.
When I plug in my webcam to a Linux machine, a simple 'dmesg' shows the following messages
1. UVC Complaint device found
2. The device is unlisted.
I am able to easily stream uncompressed frames through this webcam.
Short question: Can I read credit card information with a NFC capable Windows Phone 8?
Long question: How does NFC with credit cards exatly work? The card (or the phone with wallet function) receives a request via NFC and replies with the cleartext credit card information in some standardised format? The Wallet option then aditionally still props some comfirmation dialog before broadcasting the credit card information?
Or is there some handshake encryption going on before hand? Or is there some credit card specific secret code safeguarding the commuincation? Or is there some overlay protocol on NFC for payment? NFC ist just pushing a string over the air as far as know?
If it works, as I think it works, can I tell a Windows 8 Phone, through preferably C#, to read credit card information and display it to me (if the credit card has a chip inside)? Or does maybe Windows Phone 8 disallow access to the NFC reader, or some mystic payment protocol (if such a thing exists). My short web search was very vage on technical details, especially with some sites talking about carrier support for wallet systems, as if some keys would be fetched from somewhere in the web to secure the transactions? I can't really image something like that being standardised accross all credit card issuers.
Can someone give technical insight the way credit card data is transfered and if you can program a phone to read such data.
Contactless credit/debit cards certainly do use NFC (mainly ISO 14443-A, some mainly in France are ISO 14443-B), and their communication protocols follow an industry standard called EMV which has public specs available here: http://www.emvco.com/specifications.aspx?id=223 The cards speak the same EMV both over NFC/contactless as well as through the contact chip (eg the gold thing you insert into a reader) though payment networks tend to do things slightly differently depending on which interface is used (eg sometimes PIN not required via contactless for low amounts, whereas contact might always require a PIN). Also, certain aspects of the protocols are proprietary to the payment networks so the EMV specs don't fully describe everything.
If you search around there are various sites that give some examples of how to communicate with credit/debit cards some over NFC others with an insert chip card, but typically the commands will work the same regardless of the interface. You can buy a USB smart card reader that will do both NFC and insert/contact for http://blog.saush.com/2006/09/08/getting-information-from-an-emv-chip-card/
For Windows Phone you also can talk with credit cards as long as you have a Lumia 830/730/735 etc as the older devices (even the Lumia 930) have an older NFC chip where the driver doesn't support the smart card APIs. You can use the sample code here: https://nfcsmartcardreader.codeplex.com/ to learn how to send/receive APDU commands/responses to NFC cards though that project doesn't specifically have the commands you need for a credit card (though that other link does have the APDUs you need).
And credit cards generally all will let you read their PAN (the account number printed on the front), expiry date, and in some countries even the cardholder name (though in the US for privacy most banks tend to not expose it, instead returning stuff like "VALUED/CARDHOLDER" as the name) without any encryption or keys. It will not however return the CVV2 code printed on the back of the card, which is generally required by merchants to be able to place orders on the internet, and it also generally does not let you clone the card since there is dynamic/encrypted data required to do card present transactions at a physical merchant.
Short answer: No. It's unlikely Credit card would work with WP8.
Long answer:
RFID vs. NFC: As far as I know most credit cards don't have NFC. They have RFID. Which one could say it's a "predecessor" technology to NFC. RFID is mostly non-standardized, has longer range than NFC and only supports one-way communication. Whereas NFC is an evolving standard, can be used in 2cm-4cm range and supports two-way communication. So, WP8 does not support RFID but it does support NFC.
RFID on WP8: All that being said, there's a chance that WP8 could identify some RFID tags. You might be able read byte[] from specific RFID tags in specific WP8 phones. Obviously, that's not recommended.
Secure NFC: One last thing is that some very exclusive partners in some very specific regions will have access to "Secure NFC". Secure NFC is a superset of NFC and adds the feature to store & transmit secure information via NFC from WP8. For example Secure NFC can store a Credit Card number or a bank account number as part of the WP8 Wallet. However, That will only work in regions where the mobile operator issues a "Smart SIM" (SIM capable of running applets), where the developer can author Java based Smart SIM applets, where the developer has an agreement with the mobile operator to deploy those applets over-the-air, where those WP8 apps have been cleared with Microsoft for the WP8 store and where there are dedicated retail HW terminals that can read them.
Sorting out a bit of the above answer of JustinAngel:
RFID is not a predecessor technology of NFC
RFID covers various frequency bands of Radio Frequency Communication (e.g. HF and UHF)
NFC is Near Field Communication and usually covers HF (13.56 MHz)
Many standards fall under HF NFC: ISO14443-4, ISO15693, FeliCa, ISO18092, .....
NFC Forum is trying to unify things and uses NDEF messages to exchange semantic messages
contactless payment on credit cards is based on a contactless smartcard layer.
WP8 allows only exchange of NDEF messages
WP8 does not allow exchange on the contactless smartcard layer (ISODEP==L4==(T=CL))
see the windows proximity api for details or http://developer.nokia.com/Community/Wiki/Use_NFC_tags_with_Windows_Phone_8
Android however gives access to this ISODEP layer
I don't know what credit card information could be retrieved from an app. There is a secure element involved which handles cryptography and stuff. I don't think detailed information on Mastercard payPass or VISA payWave is freely available
Can I read credit card information with a NFC capable Windows Phone 8?
No, you cannot do that. NFC API on Windows Phone 8 is very limited.
May be Wallet API could help you somehow with your project, but this is not about NFC.
Also you could try to use Android devices with NFC, they have more powerful NFC API than WP8.
Can a WindowsCE device connect so more than one BlueTooth device? The device needs to both serve as a BlueTooth hands-free speaker for a phone and connect to a third device via a serial BlueTooth connection.
Can an application do this without the need of a speciel driver?
You must understand that Windows CE is a modular OS and any specific platform capabilities are implemented by an OEM. An OEM can create a Windows CE device with absolutely no Bluetooth support or they might choose to implement just a Bluetooth client profile (say as a bluetooth audio device) or they may choose to implement a Bluetooth server so they can consume a Bluetooth serial device. They may also choose to implement both. Beyond what the OEM does in software, the hardware itself might allow only one or the other (or both or neither for that matter).
The short of this is that we can't actually answer your question becasue there is no generic answer that fits all devices. You have to ask the Device OEM what they support and if they can extend that support if they don't support what you need.