I’ve been thinking about this lately. I wonder if in reality there are only rapid low-power reads. The high power read only happens when a disturbance in the force is detected or whatever electromagnetic measurement is made goes over a threshold.
The reason we see this low-low-low-high… pattern, in this case, would be because the low pulses would have a cumulative effect on the lc circuit that in turn passes the phone’s threshold for a high pulse to be sent…
Although I have nothing to back this up other than instinct and the fact that the pattern doesn’t seem to repeat perfectly which is suspicious.
For example, if I hold the card to the back of my Pixel I see an irregular pattern but if I place both down on the desk I only get low pulses leading me to believe that the high ones are triggered by slight movement.
Random progress update. I reordered the project a bit and did some work on the product database. It will be used both as a user facing feature but also as a reference to match scanned implants.
The fist thing in the video is the power scan keeping the LED constantly on until connexion is lost. The second is a test layout for the product database with loading images straight of the website. Of course I have a system for catching said images too but here it’s purely web queries.
I’m gonna work on these loading times, I promise.
Edit: loading times are gone
Edit 2: Changed the thread name to be more fitting
I’m trying to anticipate the UI design for my nfc multitool and would like some opinions. So far I’m aiming for something in between these two aesthetics:
But I’m not super hyped about them and it’s still pretty vague so if there are apps that you like the design of or if you can find a reference image like these that you like please send it my way
Edit: Imo the first one is a bit simple and outdated, not slick. The second one is too much and a technical challenge given that I’m working with Unity. Overall I’m going for a modernized Github color scheme with a futuristic/tech hint.
Tech wise I can now read NFC_A tags including the ID, the technologies, the manufacturer and dump all the raw content.
That’s a tiny step for humanity but a huge step for me as I’m getting the hang of using the native java android nfc functions as well as making that collaborate with a unity project.
The interesting thing is I do a read operation, itterating the block number until that fails to get the entire tag. The operation always fails at 128 even though I think the tag has 134 blocks with the last two being locked. Also the first two are marked as locked and blocked on NXP reader but I’m still reading them… Any ideas?
The guys doing the tag info app over at NXP make plenty of mistakes… trust me. I think it’s just the wrong symbol they used.
As for the blocks, it looks like 134 should be correct… hard to say what’s going on without the code snippet. How are you issuing the read command? Are you issuing a single block read command or a fast read?
ah yeah, that does work… but aren’t you getting 16 bytes per read, thus you’d want to increment by 4 not 1. no idea why you’re getting an error though… what is the exception? if you read past the end of memory with read, you should just get 00 padding on trailing bytes.
You should definitely instead check out the fast_read command … section 10.3 of the ntag spec doc.
Oh also check out the 10.1 GET_VERSION (60h) command too… you can try to detect what tag you’re talking to before scanning memory and then just know what start and end to use for FAST_READ… only works with NTAG chips though.
I didn’t go full neuromorphic UI even though I have the asset for it because it didn’t look right. Instead, I mixed aesthetics from options 2 and 4.
Of course, this is just 4 buttons. It’s still missing the rest of the layout
Just fixed that. It indeed works this way, I was stupidly discarding the extra block I was receiving.
Well it’s an out of range because I’m trying to put > 127 into a signed byte by turning my decimal iterator into a byte. So I guess the tag reads the byte as unsigned with a max of 255 rather than 127 which makes a lot more sense.
Edit: Did a whole lot of conversion bug fixing and I’m now getting 136 blocks which sounds correct…
So today I’m kinda tired of NFC so let’s explore magnets a bit.
I added a feature called the Haptic Lab where the magnet measurmet and stimulation tools will live.
I started off with a simple teslameter allowing you to compare your magnets’ strength. Eventually, when the profile and personal data will be setup I will have a way to log these measurements
Next step is to add a powerful signal generator tool to this section which I conveniently have already coded for my previous attempt at a biomagnet app
It will allow you to use your phone + a little usb accessory to stimulate your implant at various frequencies and signal. You’ll be able to explore the full spectrum of sensitivity with the convenience of an app !
Anyway here is the feature’s landing page
The signal generator to tingle your titans is in. I’m happy with how simple the UI is despite having a lot of options. Of course it will probably change, this is a draft
Did that today. I feel like they totally could have coded the actual memory size in there instead of that power of two mess avoiding the need for a lookup table though
But hey, as much as I hate hardcoding things, this is actually helpful. Now to try the fast read
The doc says EA-EB as well as EE-FF are invalid and return NAK which is inconsistent the previous statements.
I assume I fail after EF because EE and EF were read with a command involving EC as an address which is fine and the next would be F0 which is not fine anymore.
And EE and EF are filled with 0’s because that’s the NAK…
EA and EB probably pass under the radar for the same reason.
Sorry for the rambling, I kinda figured it out as I was writing. I guess now my question is how do I explore sector 1 of the 2k I2C? How do I specify the sector I’m reading? The read address only takes a single byte for the address.
Edit: Also is the best way to approach this to hard code the memory layout for every single chip and go straight through the accessible parts with a fast read or is it possible to do something more flexible where I explore the entire memory? Checking if it’s readable or not iteratively ? I can’t imagine the first option being the reasonable one
Edit: ok I found SECTOR_SELECT… Still confused as to how I can tell if a block is blocked and just spits filler 0s or if it actually empty
