Search results for:

Thanks for that explanation @fanoush!

I've got an Espruino app that changes/notifies a 240 byte characteristic at a regular interval. On the receiving end (see browser test app) I can read the characteristic value, and get the full 240 bytes, but when receiving value change notifications I only get the first 20. I'm guessing that BLE_NUS_MAX_DATA_LEN is the cause, but I haven't taken the time to look at all the places where that is used and try to figure out why it works that way. Is this an Espruino design choice due to working on a resource constrained device? Anybody know why I'm not getting the full value during notifications?

I have a Bluetooth characteristic onWrite function as so:

onWrite: function(evt) {
  let value = new DataView(evt.data).getUint32(0, /*littleEndian=*/ true);
  // Do something with value.
 },

I'd like to validate the value -something like this:

onWrite: function(evt) {
  let value = new DataView(evt.data).getUint32(0, /*littleEndian=*/ true);
  if (value < 0)
    throw 500; // Raise some kind of exception
  // value is good, do something with value.
 },

Is this supported?

Thank you Gordon.

I'm writing some BLE services and characteristics for my Pixl.js, and after uploading to RAM I always see the message "BLE Connected, queueing BLE restart for later". I have a few questions:

1. Are my BLE changes effective already (I'm guessing "no"), or do I need to first restart the Pixl.js. i.e. is a reset() equivalent to a power-down?
   
2. Are my changes lost during restart because they were only in RAM? Should I have done a save()?
   
3. Is there a way to force a BLE restart?
   
   

Thanks for any assistance.