https://devzone.nordicsemi.com/f/nordic-q-a/13887/valid-ble-random-static-addressI&#39;ve been sending various BLE addresses to the nRF51 and am getting some inconsistencies of what addresses are being deemed valid. I am using BLE_GAP_ADDR_TYPE_RANDOM_STATIC and sd_ble_gap_address_set to set the address. The value is being pulled fromen-USTelligent Community 13Wed, 18 May 2016 11:17:37 GMThttps://devzone.nordicsemi.com/thread/53063?ContentTypeID=1Wed, 18 May 2016 11:17:37 GMT137ad170-7792-4731-bb38-c0d22fbe4515:2c7d6047-2062-4020-8fb3-00efd3d127c5import11<p>Ok, I can work around this. I just wanted to make sure I was understanding the operation correctly.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/53060?ContentTypeID=1Wed, 18 May 2016 11:16:41 GMT137ad170-7792-4731-bb38-c0d22fbe4515:dc0ea752-a8cd-4685-a913-63d58df75a98import11<p>We have an external flash chip that is storing an address. When erased that is all FFs.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/53062?ContentTypeID=1Wed, 18 May 2016 06:01:57 GMT137ad170-7792-4731-bb38-c0d22fbe4515:9e71709a-c760-4bba-815f-ec37b2ec677drun_ar<p>As far as I can see from our documentation we only check that the upper two bits correspond to the specified address type. So your application has to check the address is actually random.<br /> Why don&#39;t you use the preprogrammed address to begin with instead of setting the address to 0xff...?</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/53061?ContentTypeID=1Tue, 17 May 2016 23:52:55 GMT137ad170-7792-4731-bb38-c0d22fbe4515:949dec4a-5964-4627-a3e9-ea9c19e08ff6zhwzh308<p>When you erase the flash there is no softdevice, no softdevice means no bluetooth, so <code>sd_ble_gap_address_get</code> is virtually non-existent.</p><div style="clear:both;"></div>