-
No need to hurry. The code is still in an early state and needs more work anyway.
I just found another issue calling
NRF.nfcStop();
afterNRF.nfcStart();
permanently disables the NFC until the Puck.JS is hard reset by lifting the battery.Note: I can reproduce this issue also on the official build by setting URL to undef.
-
-
-
-
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.
-
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.
-
-
Thank your for your timely reply.
How are you flashing to the Puck?
Using the NRF Toolbox.
I'll try to erase 0x1f000-0x78000 by flashing an empty image- 0x1f000 -> 0x73000 = Espruino
- 0x73000 -> 0x76000 = Saved Code
Isn't the Espruino section followed by free space for arbitrary usage?
Could moving the Espruino-free space boundary add issues? - 0x1f000 -> 0x73000 = Espruino
-
I've compiled a custom, striped down, Espruino binary ~245 KByte. It fails to boot with all lights lit up.
If I blow up the binary by adding 10 KByte to ~255 with unused .rodata my binary boots as expected. This however defeats the purpose of my build.Could someone point me to the flash layout used/expected by Puck.JS?
-
I'm also a beginner, so you might get better responses from other users.
Gordon mentioned a change for the upcomming release (v92), see http://forum.espruino.com/comments/13525853/
you might need to add
0xff20
to the advertised services.
-
-
-
-
-
Thanks for porting Espruino to the RuuviTag! I was looking forward to doing it myself but this works for me to :-).
However, it looks like the LEDs and BTN are low-active:
- LED1.write(false); // => LED is on
- LED1.write(true); // => LED is off
- digitalRead(BTN); =0 //if B is pressed
Not a big issue, can it be fixed?
- LED1.write(false); // => LED is on
-
Great! Thank your for sharing.
Have you considered using digitalPulse?
digitalPulse(LED2, 1, 100);
Flashes the LED once, for 100 ms. -
-
@dklinkman Thank you for publishing your changes. Unfortunately, it has no effect on my issue. Since my error
Error Connecting
appears almost instantly I assume some issues with privileges on the RPi. -
I've somehow missed the 20 character limit on commands. That could be the source of my issue. I'll try it as soon as possible.
@dklinkman you mentioned various other errors. I initially had different errors also. Then I switched to v90.12 (http://forum.espruino.com/conversations/297615/)
-
Retrieving sensor data works flawlessly.
d1:46:17:ce:38:85 - Puck.JS WZ (RSSI -59) 1809 => {"temp":19} 180f => {"battery":100} de:87:72:1f:9c:41 - Puck.JS BK (RSSI -73) 1809 => {"temp":8} 180f => {"battery":100}
However, transmitting commands always fails:
MQTT>/ble/write/d1:46:17:ce:38:85/nus/nus_tx => "digitalPulse(LED1, 1, 100);\n" Service 6e400001b5a3f393e0a9e50e24dcca9e Characteristic 6e400002b5a3f393e0a9e50e24dcca9e <Connect> Error Connecting
Does any one know what could cause this issue?
-
Sorry for not explaining my measurements in more detail in the first place.
I've used a CR2032 coin cell as energy source and measured the voltage drop on a 10R high precision resistor (uCurrent). Therefore the see-saw supposedly shows the different phases of the uC cycle:
- power up
- pre-processing
- transmit (I assume 3 consecutive re-transmits)
- power down
I'm using the DSO's math functions to calculate the integral (shown in purple) on channel 1 (yellow). The integral of this particular measurement is 11.44uU = 11.44uA/advertisement. However measurements are never exact. Hence I decided to state the value at ~12uA/advertisement, in my post above.
- power up
-
-
-
I recommend Blowfish http://en.wikipedia.org/wiki/Blowfish_(cipher)
It has supposedly the same security level as AES. It has even shorter blocks of 8 byte. Moreover it is significantly more efficient for long-term usage and requires very little code.It has however a significant initialization time (I expect 100 ms.) and quit a large RAM footprint 4k. If the initialization happens only once per boot the initialization time should not be an issue.
You can run any block cipher in two parallel modes - Counter Mode for Encryption and CBC Mode for Message Authentication (Cryptographically Secure CRC). Note, I basically described here the CCM mode. The last block of the CBC output is used as MAC/CRC.
Keep in mind that you should use a different initialization vector (basically a random value) for every new message to prevent static analysis of the data.
The IV may be sent in clear and often precedes the payload of each message.
Could the source of this issues be different SoftDevice or Silicon Version?