In Android,
Is it possible to get a list of all nearby NFC devices and choose one to connect to (in peer-to-peer mode)? Or poll through all of them one after another?
Thanks in advance,
Cheers.
That's not how NFC works.
The NFC radio interface is designed for very short distances only. Typically, two devices need to (almost) touch each other (with their NFC inductive loop antennas stacked on top of each other) to discover each other.
While NFC controllers technically support handling of multiple passive targets (e.g. NFC tags and other peer-to-peer devices in passive target mode), the Android system is currently designed to enumerate and handle only one target device.
Related
Is it possible that one device can connect to two different bluetooth topologies and thus process two different connections at the same time?
I have a mesh network to which several devices are connected.
One of the devices should also maintain a connection with an external bluetooth device at the same time.
Would such a thing be theoretically possible or not.
if not, are there any alternative or other ideas?
Yes, this should be doable. This is because at its core, mesh is an advert-based topology. In your above diagram, think of your green nodes as just devices sending BLE adverts to each other. This means that theoretically it should be possible for one of those devices (or even multiple of them) to be in a connection with other devices (inside or outside the mesh network). The image below shows that this capability is used to extend the range and technologies of a mesh network:-
I highly recommend going through the links below as they give a good overview of Bluetooth mesh and its evolution from Bluetooth Low Energy:-
From BLE to Mesh
Developing BLE Applications with Mesh
Bluetooth Mesh for Android Developers
I hope this helps.
I have read several articles that claim that it is not possible to emulate an RFID tag using a cell phone. I am curious if it is possible to use bluetooth to send out a beacon that is compatible with an existing RFID tag reader. It is said that RFID tags work on specific frequencies making it impossible to imitate with a cell phone using wifi or bluetooth. I would like to know if it is possible to write software to turn a cell phone into a passive RFID tag without attaching any new hardware.
RFID and BLE are different protocols requiring different hardware.
No, you can't turn a cellphone into an RFID tag unless it has RFID hardware. BLE hardware is not RFID hardware, and can't be made to act like it, just like you can use your Motorola Walkabout walkie-talkie send and receive ham radio signals.
I believe that the hardware that supports ApplePay is RFID, so if you could gain access to that, you might be able to make your Apple Pay compatible iPhone act like an RFID tag, but Apple keeps that stuff locked down tight, and I might be wrong in my understanding in any case.
What you are asking about Wifi/Bluetooth and RFID using the same hardware is not possible.
On a smartphone you can achieve this RFID tag emulation using NFC technology if your phone has a NFC chip. Today NFC is mainly about ISO14443 so the target RFID reader must also support this protocol.
Don't confuse RFID and NFC. Both technologies evolved from a common base with passive versions of both technologies using radio energy sent by a reader to either a RFID Tag (just a very simple chip containing unique identifiers with an antenna attached) or a NFC device, which sends information back to the reader using the reflected energy.
They use different protocols as #Maxime-C mentions. Most importantly, the range is quite different, with NFC it is just a few inches, where as with RFID it is several meters or more. While some RFID readers may also support NFC, I don't believe mobile phones support RFID.
In theory, it actually is possible. An RFID tag operates in radio freqs of 125khz to about 14 Mhz while Bluetooth operates at 2483.5 Mhz. The difference in bandwidth of over 2000 Mhz is enough to modulate an imitated signal of an RFID.
The problem however is how good you are in assembly programming. Although Android or linux does not require drivers to drive the Bluetooth hardware, no software/firmware technology currently exists to hammer your phone's Bluetooth adapter to give out a lower frequency by Modulation- or rather, everybody has been lazy enough to just buy a $1 to $5 RFID tag than to use a $250 phone as a convenient replacement.
You can program NFC in different modes. The mission is to send bi-directional messages. In NFC there are multiple combined operation modes you can use to accomplish this:
Option 1
Phone > reader/writer mode
Card reader > card-emulation mode
This option is using the ISO-DEP (ISO/IEC 7816-4) protocol
Option 2
Phone > peer-to-peer
Card reader > peer to-peer
This option can use multiple P2P protocols e.g. SNEP
Option 3
Phone > Card emulation
Card reader > reader/writer mode
This option is using the ISO-DEP (ISO/IEC 7816-4) protocol
I have two questions in different aspects:
Usage aspect
With all three options you have bi-directional communication and you can send basically whatever you want. Why wouldn't you use one option above the others?
Security aspect
Security in the sense of vulnerability for abusing like eavesdropping, data destruction, data modification and man-in-the-middle-attacks.
I read option 3 (HCE) is also used for e.g. mobile payment. Is this the safe option, or is option 1 also safe, when you use additional measures like data encryption?
Thanks!
Why are there different operating modes?
The initial idea behind NFC is to combine existing standards (specifically ISO/IEC 14443 contactless smartcard technology and FeliCa/JIS X 6319-4) into a system that can both communicate with existing transponders/smartcards/tags, with existing reader infrastructure and that can be used to easily communicate with dedicated NFC devices.
The initial NFC standard (ISO/IEC 18092) therefore defines the peer-to-peer communication mode based on those existing protocols. In addition to being backwards compatible, the NFC standard allows two NFC devices to (automatically) handshake a connection between two NFC devices. This is not possible in a reader+card setup: neither two readers nor two cards can communicate with each other, so roles have to be predefined in a reader/card scenario.
Therefore, initially, reader writer mode was only intended to access NFC tags (passive data storage devices) and possibly contactless smartcards. Card emulation mode (HCE or SE based) was intended for interaction with existing ISO/IEC 14443 (or FeliCa) infrastructure (e.g. readers that were already in place before the evolution into NFC). And peer-to-peer mode was introdcued specifically for the communication between NFC devices.
Why can all modes nowadays be used for pretty much any scenario?
I guess that one of the driving factors for this development was that peer-to-peer mode on Android lacks API support. On Android peer-to-peer mode is only accessible through Android Beam and consequently not really usable for bidirectional communication. Another factor might be that the peer-to-peer mode protocol stack is more complex than that of reader writer mode (NFC-DEP + LLCP (+ SNEP) + application protocol vs. ISO-DEP + application protocol).
So option 1 is mainly used because it was (before Android 4.4) the only option to implement bidirectional communication over NFC. Since Android 4.4 also option 3 could be used to build similar scenarios.
Is option 3 more secure than the other options?
No, not at all. In all three scenarios, security must be handled by the application layer. The underlying communication protocols do not employ any encryption/integrity protection/etc. mechanisms.
The reason why option 3 is prefered for mobile payment is simply the backwards compatibility aspect: Using HCE you could implement an application that interacts with existing contactless smartcard readers (e.g. as they are used in EMV payment systems).
Is there a way to create communication between devices (phones) that have bluetooth 4.0 and different RFID tags like EPS tags on products, without using extra hardware?
I search for an API that allows to use devices that have BLE (like the last android and apple phone) to scan products RFID tags and get information from them.
I know that bluetooth 4.0 uses RFID so I think that this kind of API exists, but I couldn't find it.
Also, if you used any API like this and you have the experience, please write some pros and cons, because I also search for the best that exists.
thanks very much!
Completely different wireless technology.
tl;dr
No
Bluetooth is an active transfer wireless socket protocol, and RFID is a short wave IDentification system, they do not operate on the same frequency.
I am unsure what hardware the newest iWare has, but many new Android phones have an RFID / Contactless Smart Card devices built into them, in addition to one for BLE.
NFC: What is the difference between S-beam and Android beam? Can someone explain the exact flow of Wifi-Direct/Bluetooth getting activated and transferring the data?
Explained on stackexchanged....
Even though Android Beam and S Beam serve similar purposes, they
actually work very differently and are not compatible with one
another.
Android Beam uses NFC to pair your devices over Bluetooth, then
transfers files over the Bluetooth connection. I believe it can also
transfer very small pieces of data (contacts, links, etc) directly
over NFC, as the Ice Cream Sandwich version highlights page implies:
For larger payloads, developers can even use Android Beam to initiate
a connection and transfer the data over Bluetooth, without the need
for user-visible pairing. S Beam, however, uses Wi-Fi Direct to
perform data transfers instead of Bluetooth. Their reasoning for doing
this is that Wi-Fi Direct offers faster transfer speeds (they quote up
to 300 Mbps). Therefore, this will only work with other S Beam enabled
devices, currently limiting it to communication between two Galaxy
S3s.
However, the SGS3 also supports Android Beam, so you can use that to
transfer something between a GNex and an SGS3. Here is a tutorial on
Sprint's website (should be essentially the same for other versions of
the SGS3).