nfc

[espruino-discuss]

Posted at 2016-12-07 by Bennr

Hi,

I'm probably missing something somewhere in the docs, but I'm trying to find information about how NFC works on the Puck, basically I want to change the webpage that the default code on the Puck redirects to when it comes near a phone etc.

Could you point me in the right direction, or is this something that is coming?

Thanks

[espruino-discuss]

Posted at 2016-12-07 by skinofstars

Do you mean this? https://www.espruino.com/Puck.js+Eddystone

I've not got it to work yet though.

[gfwilliams]

Posted at 2016-12-07 by @gfwilliams

I think you're after NRF.nfcURL(...)

Eddystone's the one that broadcasts a URL over BLE - to have a play you're best off installing Google's Physical Web App.

[espruino-discuss]

Posted at 2017-01-11 by user71302

Does anyone have working code example of how to read an NDEF record from a NFC Tag. I havent been able to scan for cards or read a NFC record from a card.

NRF.on('NFCon', function() { ... });

[gfwilliams]

Posted at 2017-01-11 by @gfwilliams

The NFC in Puck.js is only a programmable tag - there isn't the circuitry in the nRF52 chip to read other tags.

If you want to do that, you can attach an external reader - there are some simple modules available for common types:

http://www.espruino.com/PN532
http://www.espruino.com/MFRC522

[espruino-discuss]

Posted at 2017-01-11 by user71302

Since the nRF52 is read only tag how can I format NDEF records for different TNF types other than URI.

[gfwilliams]

Posted at 2017-01-12 by @gfwilliams

At the moment, you can't. I could add the ability to specify the raw NDEF record but there hasn't been any call for it so far. What's you use case?

[espruino-discuss]

Posted at 2017-01-13 by user71302

Seems the PuckJS with NFC should be best suited to a task with some form of dynamic message content that could contain some of the on-board sensor data or a time stamp. Also a good use case would be to setup some encrypted secure communications via BLE or wi-fi. Also firmware or software updates could be transfered through NFC. It would be most useful if you could do two way communications but read only is somewhat limited for a vast majority of use cases.

I can't think of a use case for a dynamic changing URI but would think URI with additional NDEF records with certificate or auth key would make more interesting use case. This would require ability to craft multiple NDEF records which tags allow, especially the larger tags with more bytes of memory. It is very limiting if all you can do with the PuckJS is a simple ultralight tag with a URI record. For the static URI use case it would be much better to purchase an ultralight tag which are very inexpensive and consume no power as they are powered by the reading device and provide read/write functionality.

For any kind of security use case you would need to make sure the tag had unique serial #ID/MAC that was not programmable, then you could form an NDEF record that could be encoded and validated as belonging to a specific device making for high security application. That is the advantage of NFC over BLE as it is considered more secure because of limited range (Near Field) and could be used for payment transactions. Also nice for providing secure access to specific devices.

My domain of interest is in Electric Vehicle charging and how to control access to EV charging. Also of interest is vehicle information from OBDII CAN bus for fleet, vehicle VIN, and EV State Of Charge (SOC) information. All possible use cases for the PuckJS as it is a low power consumption device, small footprint and relatively inexpensive.

If anyone is doing anything with OBDII I would be interested in a post on this topic as the PuckJS might make a good device to remote the CAN Bus info to a mobile device through BLE or NFC for some secure payment, vehicle to EV charger, or access control type applications.

John

[gfwilliams]

Posted at 2017-01-16 by @gfwilliams

I don't believe we can get proper two-way communications at the moment - I think it'd require re-writing Nordic's drivers. It is however all Open Source, so if you really wanted to do that it might be possible for you to make the changes.

I'm also not 100% sure on the ability to craft multiple NDEF records - it's something that I could possibly add if I was paid for my time, but it's niche enough that I don't think I can justify spending time on it it over other features that would be more useful to others.

With the URI - it is by no means static. You could still direct someone to a website with dynamic data in the URI itself.

Also, for CAN - maybe something like an ELM327 is a very cost-efficient way of getting a connection to the car. Then you only have to worry about providing a serial protocol to the ELM327 itself.

[espruino-discuss]

Posted at 2017-05-04 by AntiCat

I’ve recently started a project where I wanted to use NFC for a two way communication between a phone and device. For this reason I changed the Espruino NFC API to expose low level hardware access in JS. To prevent conflicts with Nordic's driver I completely removed support for NRF.nfcRaw and NRF.nfcURL. My branch instead features:

//Enable NFC (returns tag header, 10 bytes)
>NRF.nfcStart();
=new ArrayBuffer([95, 42, 58, 199, 216, 35, 65, 189, 7, 3])

//Disable NFC
NRF.nfcStop();

//Register callback to call with incoming data
NRF.on('NFCrx', function(data) { ... }

//Send response
NRF.nfcSend(new Uint8Array([0x01, 0x02, 0x03, 0x04, ...]);
//Send ACK
NRF.nfcSend(0xA);
//Send NACK
NRF.nfcSend(0x0);
//No response, wait for next command
NRF.nfcSend();

Below is a usage example that "implements" NRF.nfcURL("http://espruino.com"):

var ndef = new Uint8Array([
  0x00, 0x00, 0x00, 0x00, // |      UID/BCC      | TT = Tag Type
  0x00, 0x00, 0x00, 0x00, // |      UID/BCC      | ML = NDEF Message Length
  0x00, 0x00, 0xFF, 0xFF, // | UID/BCC |   LOCK  | TF = TNF and Flags
  0xE1, 0x11, 0x7C, 0x0F, // |  Cap. Container   | TL = Type Legnth
  0x03, 0x14, 0xC1, 0x01, // | TT | ML | TF | TL | RT = Record Type
  0x00, 0x00, 0x00, 0x0D, // |  Payload Length   | IC = URI Identifier Code
  0x55, 0x03, 0x65, 0x73, // | RT | IC | Payload | Payload, see nfcRaw ex.
  0x70, 0x72, 0x75, 0x69, // |      Payload      |
  0x6E, 0x6F, 0x2E, 0x63, // |      Payload      |
  0x6F, 0x6D, 0xFE,       // | Payload | TB |    | TB = TLV Term Block
]);

//Start NFC
var header = NRF.nfcStart();
//Inject UID/BCC into NDEF template
ndef.set(header, 0);

NRF.on('NFCrx', function(rx) {
  if(rx[0] === 0x30) { //Command: READBLOCK
    //Calculate block index
    var idx = rx[1]*4;

    //prepare data (pad to 16 bytes)
    var view = new Uint8Array(ndef.buffer, idx, 16);
    var tx = Uint8Array(16);
    tx.set(view, 0);

    //send response
    NRF.nfcSend(tx);
  } else {
    print("Unknown command: " + rx);
    //wait for next frame
    NRF.nfcSend();
  }
});

I hope my extensions are of use for the projects discussed above.

https://github.com/drandreas/Espruino/releases

[gfwilliams]

Posted at 2017-05-05 by @gfwilliams

Wow, nice! Thanks for posting up. How hard do you think it'd be to emulate the current functionality? It might make sense to build on top of that code (as presumably it cuts out the Nordic binary blob?)

[espruino-discuss]

Posted at 2017-05-05 by AntiCat

It should not be to hard. I'is all about crafting a correct tag-header 8-16 bytes and NDEF records.

Nordic's implementation drops all commands != READ

So we just need to populate a Uint8Array with tag header + ndef records and respond to READ with the appropriate blocks of 16 byte of the array.

[espruino-discuss]

Posted at 2017-05-06 by AntiCat

removed

[espruino-discuss]

Posted at 2017-05-06 by AntiCat

READ (0x30) should complete within 5ms. Do you known what the delay + execution time of a JS callback is?

[espruino-discuss]

Posted at 2017-05-07 by AntiCat

I've measured the request-response delay with my example above. It is 2.5 ms. Hence we have a good margin for additional code.

[gfwilliams]

Posted at 2017-05-08 by @gfwilliams

Thanks - that looks really promising! I'm a bit busy at the moment but I filed an issue on GitHub for this, and I'll see about rolling it in when I get some time.

[espruino-discuss]

Posted at 2017-05-08 by AntiCat

Could the source of this issues be different SoftDevice or Silicon Version?

[gfwilliams]

Posted at 2017-05-08 by @gfwilliams

The SoftDevices should be the same, and silicon seems unlikely - you're both using Puck.js? I just tried two here, from two different batches. Both work fine.

I'd be interested to see if anyone else has problems with this? I'm testing with a Nexus 10 here.

[espruino-discuss]

Posted at 2017-05-08 by AntiCat

I'm using a Puck.js 1.0e

1. Cold Boot
2. IDE-Connect
3. NRF.nfcURL("http://espruino.com");

      Start |        End | Src | Data (! denotes   | CRC | Annotation 
------------|------------|-----|-------------------|-----|------------
          0 |       1056 | Rdr |26                 |     | REQA       
    4517504 |    4518560 | Rdr |26                 |     | REQA       
    9035488 |    9036544 | Rdr |26                 |     | REQA       
   13552976 |   13554032 | Rdr |26                 |     | REQA       
   18071472 |   18072528 | Rdr |26                 |     | REQA       
   22588960 |   22590016 | Rdr |26                 |     | REQA       
   27107984 |   27109040 | Rdr |26                 |     | REQA       
   27110228 |   27112596 | Tag |44  00             |     |           
   27560128 |   27564896 | Rdr |50  00  57  cd     |  ok | HALT       
   27629472 |   27630464 | Rdr |52                 |     | WUPA       
   27631700 |   27634068 | Tag |44  00             |     |           
   27642576 |   27645040 | Rdr |93  20             |     | ANTICOLL   
   27646228 |   27652052 | Tag |88  5f  14  55  9  |     |           
   27660672 |   27671136 | Rdr |93  70  88  5f  1  |  ok | SELECT_UID 
   27672372 |   27675892 | Tag |04  da  17         |     |           
   27684368 |   27686832 | Rdr |95  20             |     | ANTICOLL-2 
   27688004 |   27693892 | Tag |51  9f  5b  a2  3  |     |           
   27702464 |   27712992 | Rdr |95  70  51  9f  5  |  ok | ANTICOLL-2 
   27714164 |   27717748 | Tag |00  fe  51         |     |           
<--- and so on --->

4. RF.nfcURL();
5. NRF.nfcURL("http://espruino.com");

      Start |        End | Src | Data     | CRC | Annotation
------------|------------|-----|----------|-----|-----------
          0 |       1056 | Rdr |26        |     | REQA      
    4516448 |    4517504 | Rdr |26        |     | REQA      
    9034464 |    9035520 | Rdr |26        |     | REQA      
   13553488 |   13554544 | Rdr |26        |     | REQA      
   18070464 |   18071520 | Rdr |26        |     | REQA      
   22588992 |   22590048 | Rdr |26        |     | REQA      
   27106464 |   27107520 | Rdr |26        |     | REQA      
   31624992 |   31626048 | Rdr |26        |     | REQA      
   36142976 |   36144032 | Rdr |26        |     | REQA      
   40662000 |   40663056 | Rdr |26        |     | REQA      
   45178976 |   45180032 | Rdr |26        |     | REQA      
   49697488 |   49698544 | Rdr |26        |     | REQA      
   54214432 |   54215488 | Rdr |26        |     | REQA      
   58733472 |   58734528 | Rdr |26        |     | REQA      
   63251968 |   63253024 | Rdr |26        |     | REQA      
   67768960 |   67770016 | Rdr |26        |     | REQA      
   72287472 |   72288528 | Rdr |26        |     | REQA      
   76805952 |   76807008 | Rdr |26        |     | REQA            

Note: The trace is reformatted to fit to line length

Some how the NFC peripheral is stuck / offline. The handshake does not even start.
I think its an error in the HAL or how it is used.

[espruino-discuss]

Posted at 2017-05-09 by AntiCat

I had an epiphany: Gordon did you use http://www.espruino.com/binaries/espruino_1v92_puckjs.zip for your tests yesterday? The behaviour seams also to depend on the compiler used.

Some weeks ago I spent one day debugging an issue, that when away, when I upgraded to the GCC defined in your documentation.

[gfwilliams]

Posted at 2017-05-09 by @gfwilliams

I've just tried again to make absolutely sure:

• downloaded and flashed 1v92 from that link
• NRF.nfcURL('https://www.google.com');
• test, ok
• NRF.nfcURL();
• test, nothing
• NRF.nfcURL('https://www.google.com');
• test, ok

Are you using that image, or are you using something that you compiled yourself?

I've also tried with my own builds here, and they work fine. I am using 5.4.1 20160919 though as I found when doing builds for release that the GCC 6 compiled binaries were a bit flakey

[gfwilliams]

Posted at 2017-05-09 by @gfwilliams

Are you taking the Puck out of NFC range before changing the tag with NRF.nfcUrl? I wonder whether that could be causing problems...

[espruino-discuss]

Posted at 2017-05-09 by AntiCat

Are you using that image, or are you using something that you compiled yourself?

Yes

Are you taking the Puck out of NFC range before changing the tag with NRF.nfcUrl? I wonder whether that could be causing problems...

Yes, but perhaps my reader does not "finish" the transfer properly and the nfc state machine is left in a undefined state.

Do you have any contacts at Nordic who might be able to comment on this?

If not, I'm fine with keeping this behaviour in an unresolved state for the moment. Perhaps we can revisit it when you are not that busy. I haven't changed anything to the start/stop code. So mine should be fine too for most people. However it's a very long stretch as long as we do not know the reason for this anomaly.

[gfwilliams]

Posted at 2017-05-10 by @gfwilliams

Yes

Just to be sure, which one do you mean? The 1v92 image from the website?

perhaps my reader does not "finish" the transfer properly and the nfc state machine is left in a undefined state.

It's possible, yes. Although presumably it's doing something different to my reader since I've tested it to death with what I have here.

I don't have a proper contact at Nordic, no. Since you have a build system set up and know your way around the code, I'd suggest you take Nordic's NFC sample code and see if you can reproduce with that - if you can, you/I can just post in the Nordic devzone and see what their reply is.

[espruino-discuss]

Posted at 2017-05-10 by AntiCat

I've used http://espruino.com/binaries/espruin­o_1v92_puckjs.zip for my regression tests.

I'm also little busy at the moment, I will try it on the weekend.

Tank you for your effort.

[espruino-discuss]

Posted at 2017-05-26 by AntiCat

After fixing the easy issue (NFC and Crash) I've now revisited this one. I've found a solution. However I hit another strange effect while checking for regressions. I've tried to bisect to find the source, but it seams to be present in stock 1v92 also. After every 2nd or 3rd NFC read, my puck doesn't return to its low power state it keeps hovering a little above 1mA.

I would appreciate if you could check this one on your side.

[gfwilliams]

Posted at 2017-05-26 by @gfwilliams

Wow, yes. Just tested. In my case literally just using NFC on a completely clean device running 1v92 bumped the power consumption up to over 1mA. That's really bad news.

I had a quick check with setSleepIndicator and it doesn't seem to be increasing the amount of wakeups/second - so it's presumably some bit of NFC hardware being left on.

I've filed an issue for it on GitHub - not sure if I'll get to look into it today, but I'll see if using the NFC code from the newer SDK fixes it. If not, I guess it's time to see if I can reproduce it with the nRF52DK and see if Nordic can find a solution.

[gfwilliams]

Posted at 2017-05-26 by @gfwilliams

Ok, fixed - looks like there's a bug in the chip's NFC hardware that needs a workaround. Rather than check for the specific chip model, Nordic checked whether you were using their development board when compiling.

If you were using their development board, they fixed it. The second you compiled something for a real device, they disabled it :( I've re-added the definition for the workaround for Puck.js, so it should now work fine - it may in fact fix a lot of this sort of issue.

[espruino-discuss]

Posted at 2017-05-26 by AntiCat

you are fast, thank your very much!

[espruino-discuss]

Posted at 2017-05-26 by AntiCat

I've done various tests.

Battery consumption is back to normal and moreover the "NFC does not work after nfcURL(undefined)" bug seams to be fixed to. This obsoletes the workaround I was preparing.

[gfwilliams]

Posted at 2017-05-26 by @gfwilliams

Great! Sorry it wasn't in there from the start - I guess I should have checked more.

Thanks for finding it though - that's massive. Just a shame all the new batch of Pucks have 1v92 on them with the issue in :)