There have been some indications the Galaxy Nexus would include an FM radio. Is there any conclusive evidence of FM ?
If Google ships the Nexus with an FM app, that would be a departure from previous practice.
The Nexus One shipped with the HTC Desire FM hardware intact, but no app.
The Nexus S did not have the Silicon Labs Si4709 FM chip that the Galaxy S did, and the Broadcom BCM4329 BT/WiFi/FM combination chip was not wired to allow FM.
This Galaxy Nexus apparently has a Broadcom BCM4330 BT/WiFi/FM combination chip like the Galaxy S2 has. But the S2 uses a dedicated Silicon Labs FM chip like the original "S1".
I doubt the BCM4330 will be wired for FM, so I'd guess there must be a Silicon Labs FM chip if the Galaxy Nexus supports FM.
I doubt Google would have created their own FM app, but who knows ? Would it be incorporated into the music app ? Would they use Samsung's FM app, perhaps modified ? Or have they decided their new music store sales will be improved if they neglect FM ?
And if there is an FM app in Google's Galaxy Nexus, can we presume that the source code will be open ?
Kess78 pointed me to Supercurio's doc here: https://docs.google.com/document/d/1a6808W2GwBkBX8x1YwaW3tYm3JSzkp87uQBNWY3TFmE/edit?hl=en_US&pli=1 .
He says : "FM Radio app is not present."
The only other FM reference there is for the Audio Codec:
Linux ALSA driver source code and its register definitions, describing basic audio hardware features available.
Main input/output type supported:
* Headphone
* Speaker
* Microphone
* Bluetooth
* Voice
* FM - digital
* SPDIF over HDMI
...
Click to expand...
Click to collapse
But IMO that doesn't prove anything. First, I don't think he has the exact source code for the kernel on the phone. I've heard the source code is expected to be released in about a month. But maybe I'm wrong, for the kernel code at least.
Second, there are "phantom" FM definitions for a number of Samsung Galaxy devices that don't have the FM chip: The Galaxy Tab, I think the Nexus S and the Galaxy S2 devices with no FM chip, such as AT&T and T-Mobile variants.
So my thinking now is that Google won't be releasing an FM app. Whether or not there's a Silicon Labs FM chip remains to be seen, but I suspect Google went cheap as with the Nexus S and there is no usable FM chip. But I'm just guessing for now.
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
htc6500uk said:
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
Click to expand...
Click to collapse
A lot of Android phones, I'd say most of them, have bluetooth chips that include support for both sending and receiving FM.
The problem is just that Android lacks a framework and API for it. ST-Ericsson submitted a framework and example app for it to AOSP that has been worked on openly in Gerrit for months with input from several Google people. Unfortunately Gerrit is still down so we don't know the latest progress but it will hopefully be officially supported in the future. Until then, we will probably see FM support for it in CM like many other phones currently enjoy.
htc6500uk said:
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
Click to expand...
Click to collapse
MAYBE.
But the Galaxy S and Nexus S are almost the same phone. Yet the Galaxy S has the Silicon Labs FM chip, while the Nexus S does not.
The same is true for some variants of the Galaxy S2. The "canonical" Samsung Galaxy S2 has the Silicon Labs FM chip, while the AT&T and T-Mobile variants appear to have omitted it.
IMO, at least 2 reasons: (1) The phone is a bit cheaper if they don't install the FM chip, and (2) Carriers want us to use their expensive data plans for streaming.
I think Google also has some interest in keeping cheap, "old fashioned" airwave radio from us. Same for Apple.
blunden said:
A lot of Android phones, I'd say most of them, have bluetooth chips that include support for both sending and receiving FM.
The problem is just that Android lacks a framework and API for it. ST-Ericsson submitted a framework and example app for it to AOSP that has been worked on openly in Gerrit for months with input from several Google people. Unfortunately Gerrit is still down so we don't know the latest progress but it will hopefully be officially supported in the future. Until then, we will probably see FM support for it in CM like many other phones currently enjoy.
Click to expand...
Click to collapse
I've spent most of this year developing an FM app for various Android devices. See my sig.
My impression is that the ST-Ericsson Android FM API is doomed. Nobody but them has committed to it. Broadcom is the biggest provider of FM combo chips and has said nothing, and continues to keep their specs secret.
Except for some Japan market Sharp models, can you show me ANY Android phone that supports FM transmit ? Stock or with developer mods ? I tried this on my TI based HTC Legend and it won't work. It needs the proper antenna (and perhaps power) connections, and I've found no phone that has that, likely because they were never designed to transmit, and were even designed to prevent transmit.
Even with a theoretically usable Bluetooth/WiFi/ FM combo chip (Broadcom or TI), if the power, antenna and audio connections are not in place, FM receive is impossible. There are several phones in my app incompatible list that never had an FM app, and that I and nobody else has ever been able to FM enable. IMO nobody will ever FM enable these without impractical hardware modifications.
so this does have an fm radio ! i seen where some say it doesn't and then I seen some that say it does, The unlocked version of the SGS2 has one but the AT&T didn't so this seems too
Technical Details:
Network
2G Network GSM 850 / 900 / 1800 / 1900
3G Network HSDPA 850 / 900 / 1700 / 1900 / 2100
Camera - 5MP
Touch Screen - Yes
Weight - 135g
External Memory - No
Memory Slot - No
Bluetooth - Yes
Vibration - Yes
3G - Yes
GPS - Yes
Connectivity
GPRS Yes
EDGE Yes
3G HSDPA, 21 Mbps; HSUPA, 5.76 Mbps; LTE
WLAN Wi-Fi 802.11 a/b/g/n, dual-band, DLNA, Wi-Fi hotspot
Bluetooth Yes, v3.0 with A2DP
USB Yes, v2.0 microUSB
Additional Features
OS Android OS, v4.0 (Ice Cream Sandwich)
CPU Dual-core 1.2GHz Cortex-A9 CPU, TI OMAP 4460 chipset
Messaging SMS(threaded view), MMS, Email, Push Mail, IM, RSS
Browser HTML
Radio Stereo FM radio with RDS
Games Yes
GPS Yes, with A-GPS support
Java Yes, via Java MIDP emulator
- NFC support
- Barometer sensor
- Digital compass
- Active noise cancellation with dedicated mic
- MP4/H.264/H.263 player
- MP3/WAV/eAAC+/AC3 player
- Organizer
- Image/video editor
- Document viewer
- Google Search, Maps, Gmail,
YouTube, Calendar, Google Talk, Picasa integration
- Adobe Flash support
- Voice memo/dial/commands
- Predictive text input
The specs you have listed are from GSMArena and "may" be wrong. The two people afaik who have the GN have said that there is no native FM radio app. At present we dont even know if the FM chip is even correctly wired inside to receive signals. If it is, then CM7 (or 8) will be able to support it.
mikereidis said:
I've spent most of this year developing an FM app for various Android devices. See my sig.
My impression is that the ST-Ericsson Android FM API is doomed. Nobody but them has committed to it. Broadcom is the biggest provider of FM combo chips and has said nothing, and continues to keep their specs secret.
Except for some Japan market Sharp models, can you show me ANY Android phone that supports FM transmit ? Stock or with developer mods ? I tried this on my TI based HTC Legend and it won't work. It needs the proper antenna (and perhaps power) connections, and I've found no phone that has that, likely because they were never designed to transmit, and were even designed to prevent transmit.
Even with a theoretically usable Bluetooth/WiFi/ FM combo chip (Broadcom or TI), if the power, antenna and audio connections are not in place, FM receive is impossible. There are several phones in my app incompatible list that never had an FM app, and that I and nobody else has ever been able to FM enable. IMO nobody will ever FM enable these without impractical hardware modifications.
Click to expand...
Click to collapse
I think the API has potential still. A reason for not seeing any commits from other manufacturers for it is that it's still not finished and polished enough to be approved by Google. If it is, I think that we will see some more action by the other manufacturers. Also, in theory the Broadcom plugin could be developed by the community since it seems one of the MIUI guys have access to confidential information about commands etc. The basic functionality could probably be implemented by information from what is currently used in MIUI and CM.
I have not seen a phone that supports FM transmit, no. That would just be a bonus though. Why do you say they are specifically designed not to transmit FM? FM transmitting with limited power (to allow close range music transfer) is legal now in many countries. Also, I know for a fact that receiving works fine in many phones in CM so at least that functionality should be possible.
blunden said:
I think the API has potential still. A reason for not seeing any commits from other manufacturers for it is that it's still not finished and polished enough to be approved by Google. If it is, I think that we will see some more action by the other manufacturers.
Click to expand...
Click to collapse
I went searching for this API last night. I couldn't find ANY sign of it except for the original posts and documentation from a year or so ago. Where is this Gerrit code ? Or any evidence of recent activity ?
AFAICT, Google has nothing to do with the SE FM API. Do you have any evidence otherwise ? NONE of the chip manufacturers has said ANYTHING about it either, AFAIK.
blunden said:
Also, in theory the Broadcom plugin could be developed by the community since it seems one of the MIUI guys have access to confidential information about commands etc. The basic functionality could probably be implemented by information from what is currently used in MIUI and CM.
Click to expand...
Click to collapse
In theory ? Probably ? I really don't want to sound harsh, but I will speculate that you are just speculating about these things. And I think you are being too hopeful.
blunden said:
Why do you say they are specifically designed not to transmit FM? FM transmitting with limited power (to allow close range music transfer) is legal now in many countries.
Click to expand...
Click to collapse
Yes, sure it's legal, with the proper FCC or whatever certifications. Those cost money, as does the engineering. The chip connections are specifically made to disable transmit. Thus, no software can enable FM transmit.
I'd be happy to learn I am wrong about any of the above. But until I see evidence, these are my current opinions based on my knowledge and experience.
mikereidis said:
I went searching for this API last night. I couldn't find ANY sign of it except for the original posts and documentation from a year or so ago. Where is this Gerrit code ? Or any evidence of recent activity ?
Click to expand...
Click to collapse
When the kernel.org servers were taken down recently it also meant that AOSP and Gerrit that were both hosted there got taken down too. When Gerrit comes up again and if they keep all the history (that's not decided yet according to jbqueru) you can see for yourself. It used to be available on the following links.
https://review.source.android.com//#change,20506
https://review.source.android.com//#change,20507
https://review.source.android.com//#change,20508
https://review.source.android.com//#change,20509
I do have a limited part of the history from 20507 on gmail but I unsubscribed after a while because it was spamming my inbox. Here is a PDF of the parts I have. Some of it is missing though.
mikereidis said:
AFAICT, Google has nothing to do with the SE FM API. Do you have any evidence otherwise ? NONE of the chip manufacturers has said ANYTHING about it either, AFAIK.
Click to expand...
Click to collapse
Google is involved as in being actively commenting and reviewing it in Gerrit at the time. They provided details of changes they wanted to see etc. and seemed to show some interest in the API. You are right though in that it was written entirely by ST-Ericsson. Also, it's not made by SE (meaning Sony Ericsson) but by ST-Ericsson, a partnership between ST-Microelectronics and Erocsson. No Sony involded.
mikereidis said:
In theory ? Probably ? I really don't want to sound harsh, but I will speculate that you are just speculating about these things. And I think you are being too hopeful.
Click to expand...
Click to collapse
This part was speculation, yes. A third party plugin would not make it into any official builds at least. What I said about someone close to MIUI having some inside knowledge about what commands to send to the chip using hci_tool to enable FM receiving, RDS etc. was based on a claim they made themselves. That claim was send to me indirectly by a researcher from this group. It started with me submitting some comments on Gerrit. It started with me being approached by ST-Ericsson (Andreas Gustafsson specifically) asking if I could provide some more information and if I wanted to help them test it. I was later forwarded a message from the mentioned research group. After some emails back and forth it turned out they needed RDS which is currently not supported for the broadcom chip drivers used in CM. I therefor suggested that he should contact the MIUI guys to find out where they got the basis for the drivers they had written. That's when he told me a that a friend of xinyu had the datasheet for it but wouldn't share it.
mikereidis said:
Yes, sure it's legal, with the proper FCC or whatever certifications. Those cost money, as does the engineering. The chip connections are specifically made to disable transmit. Thus, no software can enable FM transmit.
Click to expand...
Click to collapse
You might be right about it not being wired up for transmission of FM. Receiving works on most phones with compatible chips though as shown by it actually working in CM and MIUI.
mikereidis said:
I'd be happy to learn I am wrong about any of the above. But until I see evidence, these are my current opinions based on my knowledge and experience.
Click to expand...
Click to collapse
Now you at least know what I base my opinions on. Too bad Gerrit isn't up.
blunden said:
When the kernel.org servers were taken down recently it also meant that AOSP and Gerrit that were both hosted there got taken down too. When Gerrit comes up again and if they keep all the history (that's not decided yet according to jbqueru) you can see for yourself.
Click to expand...
Click to collapse
Thanks ! You are more familiar with this than I thought, so my apologies for assuming otherwise.
I'm surprised that 20 minutes of Google searching didn't reveal anything but a few year old documents and posts. Gerrit is still down ? Sheesh ! And that was the only place for somewhat open discussion ?
I've been working 60+ hour weeks on my Android FM app since February, and am trying to earn a meagre income from this project to keep it going indefinitely.
The reverse engineering I continue to do is VERY time consuming, generally has problems, and my app only runs on a fraction of the Android devices out there. So I am EXTREMELY interested in this API, if it has success.
I vaguely recall checking up on this API around August, probably via Gerritt. I had the impression it wasn't going anywhere very fast.
blunden said:
Google is involved as in being actively commenting and reviewing it in Gerrit at the time. They provided details of changes they wanted to see etc. and seemed to show some interest in the API.
Click to expand...
Click to collapse
OK, from your PDF I see one Google email address (Dave Sparks), as well as Broadcom and TI. Interesting...
See my next post for more...
I had an interesting email from someone working for an org with interest in enabling OTA radio on more smartphones.
I posted the Q's and A's on my app thread for anyone interested: http://forum.xda-developers.com/showpost.php?p=19242542&postcount=1601
I think he and I agree that the biggest obstacles include the lack of usable, open APIs, the secrecy of the chip documents, and the manufacturers that specifically disable FM on many devices.
blunden said:
This part was speculation, yes. A third party plugin would not make it into any official builds at least. What I said about someone close to MIUI having some inside knowledge about what commands to send to the chip using hci_tool to enable FM receiving, RDS etc. was based on a claim they made themselves. That claim was send to me indirectly by a researcher from this group
It started with me submitting some comments on Gerrit. It started with me being approached by ST-Ericsson (Andreas Gustafsson specifically) asking if I could provide some more information and if I wanted to help them test it. I was later forwarded a message from the mentioned research group. After some emails back and forth it turned out they needed RDS which is currently not supported for the broadcom chip drivers used in CM. I therefor suggested that he should contact the MIUI guys to find out where they got the basis for the drivers they had written. That's when he told me a that a friend of xinyu had the datasheet for it but wouldn't share it.
Click to expand...
Click to collapse
Yes, as soon as I read the Broadcom chip header file for the MIUI/CM FM app, I was convinced the MIUI folk had some inside info. You don't get register defines like BC_REG_SPARE0 by reverse engineering alone.
My app runs on Broadcom and TI chips using what I've learned through hard rev eng work and what I've found on the net, including that header file. I support Samsung Silicon Labs and V4L too, but those "specs" are more open.
My app also supports RDS. AFAIK, neither the CM FM app, nor the MIUI app support RDS, so I think mine is the only 3rd party Android app that does on these chips. FMTwoo works w/ RDS on Galaxy S/Silicon Labs (as does mine).
And I think my app is the only one that communicates directly through the HCI UART. I had to do that because so many devices use Broadcom proprietary Bluetooth which doesn't support normal HCI access, AFAICT.
BTW, AFAIC, the MIUI and CM FM apps are now distinct. Some call the CM app MIUI, and About still says so. The MIUI FM app for Droid X is using Motorola and TI specific libraries. OTOH, the CM TI support is based on work that I did, via hcitool and (for my app direct access to HCI).
Last I looked the ST Ericsson API was VERY rich (IMO) with a lot of potential features, including handling Audio routing, which is a big problem I deal with regularly.
And yet the only multi-chip opensource Android FM code is the CM code, which is still pretty basic. Until not that long ago it only sent commands blindly, and couldn't get values such as the end frequency from a seek command.
So I feel that unless some individual or company "champions" it, I don't see much prospect for a community API implementation that goes beyond basics anytime soon. And it's not just the FM chips, it's the audio routing system for the phone, and sometimes other things, like antenna switches.
I don't think anybody is going to retrofit current phones with this API, except perhaps on specific aftermarket ROMs like MIUI and CM. There MAY be manufacturer support for this API on future phones.
I've considered writing some plugins myself, given my codebase and info. But for now I'm just waiting to see if this API goes anywhere, and if so I will support another API in my app, in addition to the 5 current APIs, possibly with a 6th (Broadcom proprietary) in the next several months.
I'd be very interested if you could give a name of someone who might be able to share more recent info on the progress of this API.
Thanks !
mikereidis said:
Thanks ! You are more familiar with this than I thought, so my apologies for assuming otherwise.
I'm surprised that 20 minutes of Google searching didn't reveal anything but a few year old documents and posts. Gerrit is still down ? Sheesh ! And that was the only place for somewhat open discussion ?
[...]
OK, from your PDF I see one Google email address (Dave Sparks), as well as Broadcom and TI. Interesting...
Click to expand...
Click to collapse
I understand. There are a lot of uninformed posts on XDA so it can serve to be sceptical sometimes.
Gerrit seems to be relatively poorly indexed on Google, if it's indexed at all. Yes, it's still down unfortunately. It makes me kind of sad since that was the only place I've found that you see and participate in open discussions between Google and the submitter. They usually respond if you make an informed comment or ask a relevant question. Unfortunately it's very hard to get in touch with developers to discuss improvements or report mistakes made in the non-open souce apps.
mikereidis said:
[...] I've considered writing some plugins myself, given my codebase and info. But for now I'm just waiting to see if this API goes anywhere, and if so I will support another API in my app, in addition to the 5 current APIs, possibly with a 6th (Broadcom proprietary) in the next several months.
I'd be very interested if you could give a name of someone who might be able to share more recent info on the progress of this API.
Thanks !
Click to expand...
Click to collapse
I contacted both people I've spoken to at ST-Ericsson about this to ask if there has been any progress as well as if I should refer you to them. I described your interest in this and how you can potentially help out. Unfortunately one of the addresses returned a "no such user" error but one of them seems to work fine still.
EDIT: I should also once again point out after reading the Q&A post you linked to that ST-Ericsson is entirely separate from Sony Ericsson and is therefor not affected by any Sony buy out as far as I know. The thing they have in common is that they both were spawned by Ericsson and then fusioned with competitors and that they are partly owned by Ericsson.
blunden said:
EDIT: I should also once again point out after reading the Q&A post you linked to that ST-Ericsson is entirely separate from Sony Ericsson and is therefor not affected by any Sony buy out as far as I know. The thing they have in common is that they both were spawned by Ericsson and then fusioned with competitors and that they are partly owned by Ericsson.
Click to expand...
Click to collapse
Thanks ! Yes I sent an email to the one shown for Andreas Gustafsson and got that "550 No such user" bounceback. I hope that's just a spam issue and not a sign this API development is dead or struggling,
Yes the names and shifting ownerships etc. is confusing. I had thought that Sony-Ericcson was the only phone manufacturer to have committed to supporting this API.
So was it ST-Ericsson that made this commitment ? And they are a chip company, so how could they make such a commitment unless they have FM chips and were supporting the FM portion of the API, or the same for audio chips.
Basically I'm wondering if any hardware company has made any commitment to producing plugins for their hardware. Or is it all experimental at this point ? I can understand though that various Linux driver standards (such as V4L which also has a radio portion) have had little commitment from HW manufacturers, yet the "community" created drivers and apps for them.
"Geritt" naming is confusing too. CyanogenMod uses "Geritt" and they are up on their servers. So it's "Android Geritt" ?
-----
And yes, I could in theory help out. I could create plugins using my existing code. I guess this only makes sense if I open source the code.
Should I ? I don't know; There are pros and cons. It doesn't make much sense to me that I would do this for FM chips, while "rich" companies like Broadcom do nothing.
I could also do the app side, but there again, drivers are still needed. And it seems a bit more logical that the open source CM FM app be modified to use this API, or even the Qualcomm Code Aurora app.
Open source is great, but doesn't pay the bills unless some corporate sponsorship is involved.
mikereidis said:
Thanks ! Yes I sent an email to the one shown for Andreas Gustafsson and got that "550 No such user" bounceback. I hope that's just a spam issue and not a sign this API development is dead or struggling,
Yes the names and shifting ownerships etc. is confusing. I had thought that Sony-Ericcson was the only phone manufacturer to have committed to supporting this API.
So was it ST-Ericsson that made this commitment ? And they are a chip company, so how could they make such a commitment unless they have FM chips and were supporting the FM portion of the API, or the same for audio chips.
Basically I'm wondering if any hardware company has made any commitment to producing plugins for their hardware. Or is it all experimental at this point ? I can understand though that various Linux driver standards (such as V4L which also has a radio portion) have had little commitment from HW manufacturers, yet the "community" created drivers and apps for them.
"Geritt" naming is confusing too. CyanogenMod uses "Geritt" and they are up on their servers. So it's "Android Geritt" ?
-----
And yes, I could in theory help out. I could create plugins using my existing code. I guess this only makes sense if I open source the code.
Should I ? I don't know; There are pros and cons. It doesn't make much sense to me that I would do this for FM chips, while "rich" companies like Broadcom do nothing.
I could also do the app side, but there again, drivers are still needed. And it seems a bit more logical that the open source CM FM app be modified to use this API, or even the Qualcomm Code Aurora app.
Open source is great, but doesn't pay the bills unless some corporate sponsorship is involved.
Click to expand...
Click to collapse
ST-Ericsson have chips with FM, as well as complete SoCs. I think Andreas might have either changed address or company but I spoke with a guy named Ulf as well and his address worked.
Gerrit is actually the name of the review system that is written by Google and released open source. CM started using it to improve the quality of the code in the project. Usually when people refer to Gerrit it should be fairly obvious which one they are talking about based on context. I was talking about AOSP Gerrit though.
I think the plan was to get other chip manufacturers interested in writing the plugins for it as that would allow them to market yet another feature of the chip to Android phone manufacturers. The chance of a phone manufacturer including functionality that requires them to write a whole new Android hardware API is highly unlikely, unless it's something like 3D screens that is very compelling for the marketing department. For that reason it's important to get the APIs implemented.
I did not mean that you should have to do an official implementation but rather that you might help them make it easier developers to test it. As you said, the manufacturers should not expect the users to implement these plugins. I just let them know you were interested about this and might have some valuable input.
I got an update from Ulf at ST-Ericsson. Work on the API has been moved to their branch in India. I should receive contact information for that team. Not that much has happened with it since AOSP Gerrit went down except for a few bugfixes.
blunden said:
I got an update from Ulf at ST-Ericsson. Work on the API has been moved to their branch in India. I should receive contact information for that team. Not that much has happened with it since AOSP Gerrit went down except for a few bugfixes.
Click to expand...
Click to collapse
Thanks ! Yes, please let me/us know of any developments.
My first impression is that moving a project to a different country is not a good sign.
My second impression is that "not a good sign" is an understatement.
IMO, Life goes on with proprietary APIs and minor roles for ALSA and V4L.
Hi, any news about GN fm radio possibility?
bye
Has anyone heard of using an NFC enabled device to imitate a RFID gate pass? My complex won't give me another one for my fiance. I thought I could copy it, and swipe my Gnex at the gate while my fiance use the proxicard HID.
I'm ignorant of the details of the two technologies, so this is probably impossible. Worth asking. Thanks
I would sure hope not. Sounds like that would be a pretty big security risk for companies that use such cards for sensitive locations.
Sent from my Galaxy Nexus using Tapatalk 2
It is possible I believe. I know for Bamboozle that the NFC wristbands had no security and I was able to get into VIP area with no problems.
I would imagine that it is likely since I doubt that their NFC security is high.
With Regards to cloning an NFC tag and an RFID card. No it won't be possible. You have mentioned two technologies that are similar but not the same. NFC and RFID work the same in theory, but at different radio bands. Think of it like ATT phones vs. T-Mo phones. Some PC adaptors can read/write both, but the GNex can't.
Second flaw is that you probably wouldn't be able to use the GNex itself to open the door. The much more likely solution would be to use the GNex to capture the info on the old tag and write it to a different tag of the same type.
Third, and this ties into what Self Righteos Banana said about the NFC wrist bands at Bamboozle, most places don't have high security on their NFC or RFID solutions, but the software isn't quite there for GNex to fully exploit this. We were able to read the wristbands and determine that all of them, VIP, 1 day, 3 day etc. etc. had the same info stored on the tag. They were relying on the site staff to visually identify the various wristbands as well as scan to see if they were genuine. With this, a little social engineering got us into restricted access. We weren't able to rewrite the wristbands completely without altering other bits yet though. One of us wrote Hello to an unused portion of the memory, but it wrote header info in adjacent bits, not zeroes. I assume this is based on protocols that the phone (or other NFC devices use). So we were able to read and write to the tags, but could not clone them. For that I think you would still need a PC until software catches up.
EDIT: Also since this is a question, I feel I should remind you to post it in the Q&A section and not general. Also there is an NFC Hacking subforum.
Thanks a lot for the valuable info. I'll hunt around in the NFC hacking section. Sorry about posting in the wrong forum. I won't make mistake again.
I have a bunch of blank NFC tags from Texas Instruments (about 40 in total) in varying sizes (both physical and storage-wise), shapes, and casings. While I'm able to read them on my Galaxy S3, none of the apps I've tried are able to write to them.
After some poking around, I determined that these are all NFC-V tags (ISO/IEC 15693 compliant), which are apparently not NDEF-compatible. While the Android OS supports them, it provides no functionality to interface with them other than transcieve (raw read/write). Lacking the knowledge to write my own interface app, I'm reduced to research, questions, and experimentation.
Does anybody have any experience using Android to write to NFC-V tags? If so, what were you able to store and how did you do it?
https://play.google.com/store/apps/...1bGwsMSwxLDEsImNvbS5ueHAubmZjLnRhZ3dyaXRlciJd
try this app, it might work for you.
Thanks for the reply. That's actually the first app I tried, and no matter what type of data I try to write, I get the following: ow.ly/c5ubE
I've been putting a lot of my effort into getting this (ow.ly/c5uaz) app to work since it specifies NFC-V and ISO/IEC 15693 compatibility, but I still can't get it to write any data (NDEF or raw). From reading up on NFC-V, I get the impression this may be an issue with one-bit vs two-bit addressing and the app assuming which it is wrongly, but I have no way to confirm that. That said, the source for that app is available for download from its developer here (ow.ly/c5uaR) if anybody is interested in picking it apart.
Aren't they locked?
I can't give you more clues as I've just started reading about NFC.
daniel_loft said:
Aren't they locked?
I can't give you more clues as I've just started reading about NFC.
Click to expand...
Click to collapse
Not that I'm aware. I can read them, and the access conditions allow writes. TI also advertises that they're shipped unlocked and unprotected.
Having done a fair amount of research since, it seems the issue is that NFC-V tags are not part of the NFC Forum standard, and there's no standard way to store NDEF data on them. Short of writing my own app with a proprietary method of doing so, I think the only option for those tags is to wait until NXP, TI, the NFC Forum, etc decide on a standard, then all the NFC Android apps update appropriately.
Fortunately, I've since gained access to the NXP Semiconductors samples ordering system, and their MiFARE tags are differently complicated but NDEF-formatable, so I'm making some headway.
rowanator0 said:
Not that I'm aware. I can read them, and the access conditions allow writes. TI also advertises that they're shipped unlocked and unprotected.
Having done a fair amount of research since, it seems the issue is that NFC-V tags are not part of the NFC Forum standard, and there's no standard way to store NDEF data on them. Short of writing my own app with a proprietary method of doing so, I think the only option for those tags is to wait until NXP, TI, the NFC Forum, etc decide on a standard, then all the NFC Android apps update appropriately.
Fortunately, I've since gained access to the NXP Semiconductors samples ordering system, and their MiFARE tags are differently complicated but NDEF-formatable, so I'm making some headway.
Click to expand...
Click to collapse
Hm, I belive that NFCIP-2 specifies something according to vicinity cards, but I don't remember what exactly. The main problem is though that the NFC chip of the SG3, which should be PN544 (not 100% sure, but I tihnk its the same as in the predecessor, and NXP didn't release PN547 yet) does not have the capability to write vicinity cards. I think there were datasheets on this though.
Damastus said:
Hm, I belive that NFCIP-2 specifies something according to vicinity cards, but I don't remember what exactly. The main problem is though that the NFC chip of the SG3, which should be PN544 (not 100% sure, but I tihnk its the same as in the predecessor, and NXP didn't release PN547 yet) does not have the capability to write vicinity cards. I think there were datasheets on this though.
Click to expand...
Click to collapse
Can you define "vicinity" in this context? If you're referring specifically to NFC-V, you may be on to something. If you just mean proximity cards in general, though, I am able to write to MiFARE tags. Furthermore, as I understand it, with the right software behind an NFC reader/writer, you can theoretically read/write just about anything that uses 13.56MHz, simply as a result of the way the active field works.
Additionally, you seem to be correct about the NFC chip in the S3 (see ow.ly/foV15), but according to the NXP spec sheet for that chip (ow.ly/foUYj), it should be able to read/write tags that meet the same ISO standards as my TI tags. Apologies for the shortened URLs; I don't have enough posts yet to post links and that seems to be the only way to get around it.
rowanator0 said:
Can you define "vicinity" in this context? If you're referring specifically to NFC-V, you may be on to something. If you just mean proximity cards in general, though, I am able to write to MiFARE tags. Furthermore, as I understand it, with the right software behind an NFC reader/writer, you can theoretically read/write just about anything that uses 13.56MHz, simply as a result of the way the active field works.
Additionally, you seem to be correct about the NFC chip in the S3 (see ow.ly/foV15), but according to the NXP spec sheet for that chip (ow.ly/foUYj), it should be able to read/write tags that meet the same ISO standards as my TI tags. Apologies for the shortened URLs; I don't have enough posts yet to post links and that seems to be the only way to get around it.
Click to expand...
Click to collapse
ISO15693 is the vicinity card standard (basicly the same as the other ISO14443 standard, but those ISO15693 cards have a bigger range up to several meters). Cards that can be read via NFC-V are vicinity cards / tags. Though I checked again, you are right, coming from the data sheet, it should be able to read and write them.
Btw, your idea to be able to read and write anything that uses 13.56MHz is to idealistic. There are many kinds of cards and standards with many different protocols (many of them are even proprietary, like Mifare Classic, Legic, iClass etc.) involved in this. These protocols are most of the time implemented on the hardware level. One of the reasons for that is the fact that there are also very strict timings cards, tags and reader have to comply to. Going up layers of software can be to slow in that case.
You can read most of the ISO 14443 A and B compliant cards for example, but Mifare Classic can only be read with phones that feature chips that implement the ISO 14443-3 A protocol. The PN544 can read Mifare Classic, because hes manufactured by NXP, the same company that holds the patents and rights of the Mifare Classic standard.
Damastus said:
ISO15693 is the vicinity card standard (basicly the same as the other ISO14443 standard, but those ISO15693 cards have a bigger range up to several meters). Cards that can be read via NFC-V are vicinity cards / tags. Though I checked again, you are right, coming from the data sheet, it should be able to read and write them.
Btw, your idea to be able to read and write anything that uses 13.56MHz is to idealistic. There are many kinds of cards and standards with many different protocols (many of them are even proprietary, like Mifare Classic, Legic, iClass etc.) involved in this. These protocols are most of the time implemented on the hardware level. One of the reasons for that is the fact that there are also very strict timings cards, tags and reader have to comply to. Going up layers of software can be to slow in that case.
You can read most of the ISO 14443 A and B compliant cards for example, but Mifare Classic can only be read with phones that feature chips that implement the ISO 14443-3 A protocol. The PN544 can read Mifare Classic, because hes manufactured by NXP, the same company that holds the patents and rights of the Mifare Classic standard.
Click to expand...
Click to collapse
Which leaves us pretty much back where we started.
As for my "WORKS WITH EVERYTHING" comment, you're absolutely right. I should have specified ISO14443/15693 (and even then my original statement would be wrong). Basically, I was referring to the fact that if you have the command set for something that operates on the 13.56MHz frequency, you can in theory write software to interface with it, as you can send and receive pretty much any raw data you want. However, you're right--there are plenty of 13.56MHz devices, both passive and active, that some active modules simply cannot communicate with.
i know precious little about the nitty-gritty of RFID or NFC stuff, but i'm wondering if there's such a thing as an RFID or NFC spoofer (emulator) that works at the standard nfc frequency of 13.56mhz, and uses the iso 14443 standard.
i'm wondering if it's possible to spoof those sky-landers figures, which use nfc. it's currently impossible to write one figure onto another because of access restrictions on the first little block in the rfid tag. and I'm not aware of any commercially available generic RFID tags that have *quite* the same hardware as the figures.
I believe the sky-landers use MiFare Classic tags, and have a locked block 0 (or UID), in that block 0 is the code which says which character they are.
is it in principle, possible to "project" a fake MiFare tag from an nfc equipped phone, also with a fake UID?
for that matter, are there any breakout boards that can do this, like an arduino shield?
*BUMP*
I'd also like to pull this off with my G-Nex...
The breakout board I use is from Adafruit.com which at the moment is hooked up to a raspberry pi. You could theoretically spoof a tag if you will. But I don't follow the logic to do so. I think what you want to do is more like cloning and siphoning. Check over on the Kali Linux forums, new version of backtrack they are working on something that does just that. I read a little into it about how they were basically bumping into people at a conference or getting in range of someone with there phone out texting or not paying attention and we're able to do just that.
Sent from my SAMSUNG-SGH-I747 using xda premium
Osbor said:
i know precious little about the nitty-gritty of RFID or NFC stuff, but i'm wondering if there's such a thing as an RFID or NFC spoofer (emulator) that works at the standard nfc frequency of 13.56mhz, and uses the iso 14443 standard.
i'm wondering if it's possible to spoof those sky-landers figures, which use nfc. it's currently impossible to write one figure onto another because of access restrictions on the first little block in the rfid tag. and I'm not aware of any commercially available generic RFID tags that have *quite* the same hardware as the figures.
I believe the sky-landers use MiFare Classic tags, and have a locked block 0 (or UID), in that block 0 is the code which says which character they are.
is it in principle, possible to "project" a fake MiFare tag from an nfc equipped phone, also with a fake UID?
for that matter, are there any breakout boards that can do this, like an arduino shield?
Click to expand...
Click to collapse
In theory one is able to emulate a NXP MiFare Classic card using an Android device. However, the firmware of the NFC chip is programmed to produce a different UID with each transmission, therefore the new firmware for the chip would have to modified to produce a static UID. If you want to learn more of the capabilities of the NXP NFC chips used in most Android devices, navigate to NXP's website and there is plenty of info.
From The Q, Of Course
live the life you love, love the life you live