Avatar for cefitzger

cefitzger

Member since Feb 2019 • Last active Apr 2019
  • 1 conversations
  • 10 comments

Most recent activity

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    This is really difficult to pin down. It's occurs when an NRF.updateServices is called while there is a queued BLE restart. It doesn't seem to be a problem with one or two characteristics, but the heavier the load the more it occurs. I've tried moving the updates out of init() but it seems not to make a difference.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    Ok, have it again and the sequence that got me there. I'll ensure consistent reproducibility and provide the sequence.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    Sorry, been trying to recreate it for the last hour but can't. This is strange as I was even resorting to erasing entirely the flash before loading code to ensure there was no residual old code interfering with the setup and still I was getting the multiple identical services and the BLE Data Size error.
    I've removed the NRF.setServices({}) from init() and will monitor to see if it happens again.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    Here's a complication to the issue that I stumbled into. I'm saving code to RAM (Pixl 2v01) and in the code I have block setting the NRF services (with 4 characteristics using the short hex UUIDs), just as in the example in the API documentation. I then update the services when a button is pressed using NRF.updateServices which works as expected, until the device is restarted.
    On restarting it adds a second instance of the same service (as seen by nRF Connect and LightBlue). Restarting again (e.g. by running a load() command) I get a third instance of the same service at which point I'm running into BLE Data Size errors when I try to update the service.

    I've resolved it by putting a NRF.setServices({}) in the init() function, blanking the services and setting the services again right afterwards but it seems wrong that the peripheral can advertise multiple instances of the same service (same name, same characteristics). It also makes updating the code tricky as you have to make sure that there is no definition of the services in RAM that might be appended to the new code when it is saved.

    I can understand that where you want to change the characteristics of a service you need to delete and re-instantiate it but should there not be a check that prevents the same service being advertised multiple times?

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    Sorry about the delay in replying and hanks for the pointer to GitHub. I'll work a bit more on it next week when hopefully I'll have a bluetooth dongle to sniff the packets with WireShark.
    iOS takes the approach that it's up to the peripheral to decide if it wants to implement any security - there's no way to force it from that side.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    Thanks for this post. I was also struggling to see the new services I was adding until I read this a second time and 'saw' the iOS qualifier. I was so focused on the Pixl that I forgot about the iPhone's bluetooth 'memory'. My bluetooth scanner (nRF Connect) is also on the phone so it didn't 'see' any change and kept reporting the service I deleted.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    BTW, I've tried the NRF.setSecurity({passkey:"123456", mitm:1, display:1}); to no avail using 2v01.35 of the firmware.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    Is there any Api documentation for NRF.setSecurity options (e.g. keyboard:1)? I want to use a Pixl as a peripheral (no keyboard attached) but force bonding and whitelisting. The central is an IOS app.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for cefitzger

    Great, that worked. I had tried holding BTN1 for > 10 seconds (read it somewhere on the site) but got nothing.
    Thanks

Actions