Are those going to be something up on DangerousThings.com? If not, where’d you end up getting them?
The super strange thing is i tested it on a i2c test card and it worked fine 
1 Like
Yes they will be and yes I’ll send you some asap
1 Like
So it loks like the problem mentioned above by @Devilclarke most likely has to do with this:
I was not aware of this problem, as I don’t have an xSIID installed, nor do I have any NTAG i2C devices. After I get a few, I’ll start messing around with the special care that this device needs in order to take full advantage of the 2K bytes of memory it’s got. I’m just about to start with programming up some of the base activities, fragments and utility classes for the DangerousNFC 2.0 application (after I finish mocking up the UI, writing some base logic out, and running it by @amal ). We’ll have plenty of motivation with that project to make sure the xSIID is fully “writable”.
5 Likes
Beautiful!!! Can’t wait to get my hands on one.
After much back and forth with NXP over the issues with the xSIID and accessing all 2k, it appears that android and iOS simply choke on trying to read ndef data that skips over a reserved section… and after reviewing the NFC Type 2 forum specification, there clearly is no provision for handling memory topography like that. The Memory TLV definition simply handles a single reserved section but there is no provision for reading memory beyond it, so basically the phones and reader chips in the phones can easily access that extended memory sector on 2k NTAG I2C chips, and you could also easily write your own mobile applications to do so, in the end the NFC library functions in both phone OSes which read and parse the data simply trip over it and land on their faces.
As such, these cards currently have 2k chips but they have been set up with a CC (capability container) that only addresses the first 1k for NDEF data. New cards, if they are made, will have 1k chips. The same is likely to be true for the next batch of xSIID as well.
3 Likes
2K… Pff… 640 bytes ought to be enough for anybody.
1 Like
If I make a gif that small, can it be scanned to show that by anyone?
I was thinking that when I saw your post the other day. I will give it a shot.
curious what NDEF record type is used for that?
Either NFC forum external type (TNF 4) or unknown (TNF 5) works with Android. When Android sees one of those two types, it grabs the first string in the text record and interprets it as a mime type - in this case, text/vcard, but it can be anything as long as Android can match it to an intent.
This is non-standard though. Pretty much Android-specific behaviour. However, seeing as though Android is a kind of a de-facto standard… 
1 Like
Man, that really sucks.
I don’t suppose we’ll see any way to get access that extra bit of memory then. It looks like Ultralight android APIs allow for specific page indexes when writing raw bytes, but there’s nothing of the sorts that I can see that would work with the i2c where we could maybe skip that reserved section manually. Nothing to extend/modify either that I can find. It doesn’t seem like the code for how android handles read/write operations under the hood is even available, and what is available isn’t granular enough to be able to modify for different results.
1 Like
Yep thats what I got from nxp was talking to them as my work may have an application for the i2c (allowing customers to store settings for our device and update them via ther phone).
The litteral response i got from nxp was “the 2nd sector is not meant for ndef data” when I asked what it was for then I was told “whatever your application wants to write but it can’t be read with a phone”.
1 Like
Just to be perfectly clear, it can be read with a phone perfectly fine… as in your application can read and write to sector 1 no problem… it’s just the OS ndef procedures will fail to properly navigate to it in the process of automatically reading memory sectors during an ndef intent. You could, in theory, write your own code to pull the entire ndef data tlv down and like, force it into the ndef intent for parsing… but pretty sure you’d need root to have the phone accept it and process it.
It’s a nuance that’s irrelevant for most people, but important to understand exactly what the problem is so we can find that one dev responsible at Apple and Google so we can harass and shame them hahah
1 Like
Yeah sorry that wasn’t very clear they said it won’t be able to be seen as 1 contiguous block of ndef data.
2 Likes
I know I could get it to read the payload correctly, albeit with some real manual elbow grease, just from manually parsing the raw payload like you said. I’ll try testing that approach in the new DangerousNFC application soon. However, writing seems to be 100% out of the question. if there was a way to write raw bytes at specified indices of memory on something like the i2c, then it would probably be manually feasible, but I see nothing of the sort on Android.
Yep you absolutely can manually write data to specific memory pages… check the dangerous NFC source… that’s all I’m doing is manually writing stuff But, the ndef library that normally takes your payload data and handles encapsulating it into an ndef message and subrecord and then splits it all up and writes it to contiguous memory pages for you… yeah that also doesn’t work when wanting to automatically write across multiple sectors on an ntag i2c… damn shit works across sectors of a Mifare classic… but that’s it’s own band-aid non-nfc special crap nxp bunged into android codebase.
3 Likes