Most recent activity
-
Thanks +Gordon for your replies. I will update the Puck tomorrow and hopefully it will fix the issues at the start.
Also I was wondering where is the code that I uploaded stored in the Puck? Is it in the RAM or the flash memory?
Cause I noticed that everything that I have uploaded seems to be lost once I take the battery out/do reset(). So does the Puck not retain any previous uploaded code once the power is lost/resetted?
If I use therequire("ble_simple_uart").write()function above to write new commands to another Puck, what happens to the code previously stored? (e.g. I declared an exec() function like you mentioned) Is it overwritten or appended to the end?Thanks for your help again :)
-
Hi +Gordon,
I am doing some tests on BLE UART using the ble_simple_uart module from the guide at http://www.espruino.com/Puck.js+BLE+UART
Using the guide, I am able to program a Puck to "forward" the commands sent from the PC (Web Bluetooth IDE) In this case, I am able to turn on the LED of a second Puck without prior programming on that Puck.
The code that I am using is:
NRF.requestDevice({ filters: [{ namePrefix: 'Puck.js' }] }).then(function(device) { require("ble_simple_uart").write(device, "digitalPulse(LED3,1,1000)\n", function() { print('Done!'); }); });However, I have some questions:
- When I upload the code I sometimes get the error
Uncaught Error: Unhandled promise rejection: undefined, it seems to be pretty random as I am able to get it to work after reuploading the code a few times. Why does this happen? (My Pucks are on 1v88) - When I try to send a Eddystone broadcast command using this method e.g.
require("ble_eddystone").advertise("goo.gl/B3J0Oc");I am unable to detect the Eddystone broadcast using Beacon Tools app on my phone. Disconnecting and reconnecting the second Puck ends up with a Connection error. In the end I am forced to reset the second Puck by pulling out the battery. Is it possible that the UART connection will interfere with the Eddystone broadcast? Currently I am only testing on two Pucks, but is there an efficient way to make the code "recursive", such that if I add more Pucks and they are only in range of the second Puck, I can make the second Puck search for other Pucks nearby, then send the command again? I know that one way to do it is to put the whole code in the "commands to be sent field" i.e.
NRF.requestDevice({ filters: [{ namePrefix: 'Puck.js' }] }).then(function(device) { require("ble_simple_uart").write(device, "NRF.requestDevice({ filters: [{ namePrefix: 'Puck.js' }] }).then(function(device) {\n require('ble_simple_uart').write(device, 'digitalPulse(LED3,1,1000)\n', function() {\n print('Done!');\n });\n });\n", function() { print('Done!'); }); });
But this will only make the command broadcast 2 times in total which does not help if the number of Pucks increase. It would be great if the command becomes recursive so that each Puck that receives the broadcast can turn on the LED + search for other Pucks nearby and send them the command. Does the Puck have some functions to do this?
#4. What is the maximum command length that the
require("ble_simple_uart").write()function supports?Thanks.
- When I upload the code I sometimes get the error
-
Yea, I am trying to filter out all the other Puck devices transmitting using Eddystone format.
But now I am facing an issue of getting the data out, as the data is stored in the
devices[i].dataobject. Now I am using a for loop to get each item in thedevices[i].dataobject, then store it in another array. As I am not familiar with the js ArrayBuffer object.new ArrayBuffer([3, 3, 170, 254, 26, 22, 170, 254, 16, 248, 3, 49, 50, 51, 52, 53, 54, 55, 56, 57, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75]) -
Hi, you are correct that my Puck is now still on 1v88. I didn't update it because I have some other projects in progress and I don't want to potentially affect them through updating.
I changed
0x13to0x14then add one more character to the message and it worked! Now I found that the maximum value is0x1Aand the entire message is now 31 bytes just as you mentioned.Working: (31 bytes total)
NRF.setAdvertising([0x03, // Length of Service List 0x03, // Param: Service List 0xAA, 0xFE, // Eddystone ID 0x1A, // Length of Service Data 0x16, // Service Data 0xAA, 0xFE, // Eddystone ID 0x10, // Frame type: URL 0xF8, // Power 0x03, // https:// '1','2','3','4','5','6','7','8','9','A','B','C','D','E','F','G','H','I','J','K'], {interval:100});Any further extension will result in BLE Error Code 9 but that is to be expected, I think.
I am aware that the Eddystone library exists, but I am using this manual way to verify if the message can be maximum 31 bytes long.
Now I am able to use
NRF.findDeviceson the receiving beacon to read the information from other Bluetooth beacons nearby. I am looking into a way to filter out everything except the Puck's broadcast. One way I suspect this can be done is using theserviceskey in thedevicesobject as the broadcasting message has thefeaavalue. Though I have zero experience in js so I think this will take a while.BluetoothDevice { "id": "e3:55:93:0b:72:1d random", "rssi": -66, "services": [ "feaa" ], "data": new ArrayBuffer([3, 3, 170, 254, 26, 22, 170, 254, 16, 248, 3, 49, 50, 51, 52, 53, 54, 55, 56, 57, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75]) }Many thanks for you help.
-
Hi Gordon, thanks for your reply.
I am currently testing out the Eddystone broadcasting function using the
NRF.setAdvertising
examples in the documentation. But when testing the maximum message length that can be sent using Eddystone format, I received an error once the message exceed 24 bytes. I heard that the maximum length supported for a Bluetooth advertising packet is 31 bytes. So why is the packet that I can send much shorter than expected?The code that i used is:
NRF.setAdvertising([0x03, // Length of Service List 0x03, // Param: Service List 0xAA, 0xFE, // Eddystone ID 0x13, // Length of Service Data 0x16, // Service Data 0xAA, 0xFE, // Eddystone ID 0x10, // Frame type: URL 0xF8, // Power 0x03, // https:// '1','2','3','4','5','6','7','8','9','A','B','C','D','E'], {interval:100});Will result in:
>Uncaught Error: Got BLE error code 9 at line 1 col 37 NRF.setAdvertising(d, {interval:100});Interestingly enough, I saw your answer on another iBeacon question which uses the code below and it works on the puck with a packet size of 30 bytes:
var d = [0x02, // Number of bytes that follow in first AD structure 0x01, // Flags AD type 0x04, // Flags value 0x1A = 000011010 // bit 0 (OFF) LE Limited Discoverable Mode // bit 1 (OFF) LE General Discoverable Mode // bit 2 (ON) BR/EDR Not Supported // bit 3 (OFF) Simultaneous LE and BR/EDR to Same Device Capable (controller) // bit 4 (OFF) Simultaneous LE and BR/EDR to Same Device Capable (Host) 0x1A, // Number of bytes that follow in second (and last) AD structure 0xFF, // Manufacturer specific data AD type 0x4C, 0x00, // Company identifier code (0x004C == Apple) 0x02, // Byte 0 of iBeacon advertisement indicator 0x15, // Byte 1 of iBeacon advertisement indicator 0xe2, 0xc5, 0x6d, 0xb5, 0xdf, 0xfb, 0x48, 0xd2, 0xb0, 0x60, 0xd0, 0xf5, 0xa7, 0x10, 0x96, 0xe0,// iBeacon proximity uuid 0x00, 0x00, // major 0x00, 0x00, // minor 0xc5]; // The 2's complement of the calibrated Tx Power NRF.setAdvertising(d, {interval:100});Now I am not sure if this is a Puck issue or a Eddystone issue. Hope you can help me out. Thanks in advance :)
Hi there,
I am planning to use the Puck's GPIO pin to detect if a switch is open (it will be closed most of the time), however I was wondering if the GPIO pin mode will affect the battery drain? My original idea is to connect the switch to both a GPIO pin (as input, pull down) and the 3V pin. But is there a better design that will save more power?
Thanks.